Timeout Configuration

The timeout parameter limits how long a pipeline can run before being automatically cancelled. This recipe shows how to set timeout values to prevent jobs from running indefinitely.

Complete YAML

name: Build with Timeout
platform: ios
environment:
  xcode: "16.4"

triggers:
  - push
  - pull_request

timeout: 30

steps:
  - name: Build
    run: fastlane build

Timeout Values

# 10 minutes (shortest reasonable timeout)
timeout: 10

# 30 minutes (default for most iOS builds)
timeout: 30

# 60 minutes (for slower builds)
timeout: 60

# 120 minutes (for very large projects)
timeout: 120

Examples by Build Type

Quick Builds

name: Unit Tests
platform: ios
environment:
  xcode: "16.4"

timeout: 15

triggers:
  - push
  - pull_request

steps:
  - name: Install pods
    run: pod install

  - name: Run tests
    run: fastlane test

Standard Builds

name: iOS Build
platform: ios
environment:
  xcode: "16.4"

timeout: 30

triggers:
  - push

steps:
  - name: Install gems
    run: bundle install

  - name: Install pods
    run: pod install

  - name: Build app
    run: fastlane build

Large or Complex Builds

name: Full Release Build
platform: ios
environment:
  xcode: "16.4"

timeout: 90

triggers:
  - push

steps:
  - name: Install gems
    run: bundle install

  - name: Install pods
    run: pod install

  - name: Run comprehensive tests
    run: fastlane test

  - name: Build release
    run: fastlane build

  - name: Deploy
    run: fastlane beta

Key Points

Tip

Choose timeouts that give your build enough time to complete, but not so long that hanging processes waste resources. Most iOS builds complete in 20-40 minutes.

• Timeout Unit: The timeout value is specified in minutes
• Job Cancellation: When timeout is reached, the job is automatically cancelled and marked as failed
• No Partial Completion: If a step is running when timeout occurs, it’s terminated (no cleanup of partial artifacts)
• Default Behavior: If no timeout is specified, RunnerHub uses a platform-specific default (typically 60 minutes)

Timeout Strategy

Estimate Build Time

# Add 20% buffer to your typical build time
# If builds usually take 25 min, set timeout to 30 min
timeout: 30

Monitor and Adjust

# Start conservative, increase if builds timeout
# Week 1: timeout: 20
# Week 2: After one timeout, increase to: timeout: 30

Environment Variables

# For variable build times, use higher timeout
name: Conditional Build
platform: ios
environment:
  xcode: "16.4"
  variables:
    BUILD_TYPE: $BUILD_TYPE

triggers:
  - push

timeout: 45  # Accounts for slower days

steps:
  - name: Build
    run: fastlane build

Handling Timeouts

If your job times out:

1. Review logs to identify slow steps
2. Optimize dependencies — remove unused pods, gems, or packages
3. Parallelize steps where possible (e.g., run tests in parallel)
4. Increase timeout temporarily while optimizing
5. Cache dependencies — leverage RunnerHub’s built-in caching

Slow Step Detection

name: Build with Timing
platform: ios
environment:
  xcode: "16.4"

timeout: 40

steps:
  - name: Install gems
    run: |
      echo "Starting: $(date)"
      bundle install
      echo "Finished: $(date)"

  - name: Install pods
    run: |
      echo "Starting pod install: $(date)"
      pod install
      echo "Finished pod install: $(date)"

  - name: Build
    run: |
      echo "Starting build: $(date)"
      fastlane build
      echo "Finished build: $(date)"

Caution

Timeouts that are too short will cause valid builds to fail. Use timeout for safety, not as a performance metric. If you consistently hit timeouts, optimize your build instead of increasing the timeout indefinitely.

Best Practices

1. Set reasonable timeouts based on typical build duration
2. Leave headroom — don’t set timeout equal to expected duration
3. Monitor timeout failures in your CI/CD dashboard
4. Optimize slow builds rather than extending timeouts
5. Use separate timeouts for different pipeline types (tests vs. builds)