GitHub Actions `timeout-minutes`: the default, the cost, and what to set

Every job in a workflow can carry a timeout-minutes value. Leave it out and GitHub applies its default: the job is cancelled after 360 minutes, six hours.

jobs:
  test:
    runs-on: ubuntu-latest
    timeout-minutes: 15
    steps:
      - run: npm test

What is the default timeout for a GitHub Actions job?

A job on a GitHub-hosted runner is cancelled after 360 minutes (six hours) unless timeout-minutes sets a lower limit. A hung job therefore holds the runner, and on a private repository bills minutes, for up to six hours.

Why the default hurts

Most CI jobs take minutes. When one hangs — a deadlocked test, a dependency download that stalls, a command waiting for input that never comes — nothing stops it until minute 360. The runner is held the whole time, and on a private repository every one of those minutes is metered against your plan. GitHub documents higher minute multipliers for Windows and macOS runners than for Linux, so the same hang costs more there; check GitHub's current billing page for the live numbers.

A value of 360 is not a guard

Writing timeout-minutes: 360 restates the default. It looks like a limit and limits nothing, which is why the checker flags it separately.

Choosing a value

Look at how long the job normally takes in your run history, then set the limit at a few times that. A test job that takes 4 minutes can carry 15.
Too tight a limit cancels healthy runs when the runner is slow, so leave headroom rather than aiming at the average.
Put it on the job, not on a step. A step-level timeout-minutes bounds that one step only.
A job that calls a reusable workflow (uses:) cannot take timeout-minutes; set it on the jobs inside the called workflow.

Check your own workflows

Paste your workflow YAML into Actions timeout-minutes Check to find every job without a job-level limit across all your workflow files at once, or run the CLI in your own repository:

python3 check.py --fail-on-risk

That exits with a nonzero status if any job has no timeout or restates the default — wire it into your own CI to block a new one before it merges.