Timeouts

~8 min · timeout, hangs, reliability

Level 0Apprentice

0 XP0/101 lessons0/10 achievements

0/120 XP to next level120 XP to go0% complete

The default 6-hour job timeout is wrong for almost everything

Without an explicit timeout, jobs can run for up to 6 hours. A hung process — a test waiting on a flaky external service, a docker pull stuck on a registry outage — can quietly burn through your CI budget for half a day.

Set tight timeouts:

timeout-minutes: at the job level — cap the whole job.
timeout-minutes: at the step level — cap an individual step.

Sensible defaults

Job type	Reasonable cap
Lint / format	5 minutes
Unit tests	10–15 minutes
Integration / e2e	30–45 minutes
Deploy	15–30 minutes
Release pipeline	60 minutes

If your job hits the cap, the run fails. That's the correct behavior — investigate why it took so long.

Code

Job + step timeouts·yaml

  test:
    runs-on: ubuntu-latest
    timeout-minutes: 15        # whole-job cap
    steps:
      - uses: actions/checkout@v4
      - run: pip install -e '.[dev]'
        timeout-minutes: 5     # install must not hang
      - run: pytest -q
        timeout-minutes: 10    # tests must complete in 10

External links

GitHub — Job and step timeouts

Exercise

Add timeout-minutes to every job in your workflows. Use 1.5× the recent p95 runtime as the cap. Push and watch a few runs to confirm none get clipped.

Progress

Progress is local-only — sign in to sync across devices.

← PreviousConcurrency Next →Continue on Error

Spotted a bug or have feedback on this page?Report an Issue

Comments 0

🔔 Reply notifications (sign in)

No comments yet — be the first.