Put time limits on jobs that can hang
Set job timeouts from normal run history so stalled checks release runners and produce a failure that can be investigated.
How companies used this technique
Read what each company changed and follow the original sources.
Bound flaky job runtime
Anthropic describes running tests that were already flaky or failing across the board. As a StarSling pattern for GitHub Actions, a timeout set from successful run history stops a hanging job from holding a runner for six hours.
- Use it when
- A non-matrix integration job has timed-out runs near the 360-minute default and at least three successful runs to measure.
- Before applying it
- A timed-out required check still blocks the merge, so the hanging tests get fixed by name.
Bound integration jobs that can hang
Mastra added explicit timeouts to integration and change-detection jobs, then broadened timeout coverage. Later checkout timeouts were lengthened, showing why the bound needs observed tail data.
The combined store workflow keeps its job timeouts in test-combined-stores.yml. Source
- Use it when
- A database, checkout or external service occasionally hangs beyond useful execution time.
- Before applying it
- A timeout caps the runner minutes a hung job can burn. Leave room for normal tails and diagnostics.
Bound a test job that can hang
After tests looped indefinitely during development, Job Iteration added a five-minute timeout to a build matrix that normally runs in under a minute. A hung leg now stops at five minutes; the platform default is 360.
Merged 2026-06-04; the timeout is on the default branch. Source
- Use it when
- A job with no timeout-minutes can stall and hold a runner until the platform default.
- Before applying it
- Set the ceiling from the job's real duration with headroom for cold setup.
Cap hung test jobs with timeouts
The confidence-sdk-flutter iOS test job could hang on the simulator and run for six hours. The change adds a 45-minute job timeout and a 30-minute timeout on the integration test step, boots the selected simulator before the tests and removes the blocking simctl bootstatus wait.
- Use it when
- A job sometimes hangs and runs until the platform's default limit, six hours on GitHub-hosted runners.
- Before applying it
- Set each timeout well above the longest healthy run so slow runs still finish; the passing iOS run on this change took 6m34s against a 45-minute cap.
Company Playbooks
- Read Anthropic’s playbookRun only affected tests
- Read DoorDash’s playbookRun build and test in parallel, sharded across CI agents
- Read Linear’s playbookBenchmark the same job on faster hardware
- Read Mastra’s playbookStarSling runners for the slowest test workflow
- Read OpenAI’s playbookRank CI fixes by the minutes they save
- Read Ramp’s playbookMove a CPU-bound test suite to a faster CPU
- Read Shopify’s playbookLet an agent iterate against one CI metric
- Read Spotify’s playbookBuild arm64 on native arm64 runners
- Read Stripe’s playbookRun only the tests a change can reach
- Read Uber’s playbookBuild the merge-queue speculations most likely to be needed