GitHub Actions step killed because timeout-minutes was exceeded
A step or job ran longer than its timeout-minutes value, so the runner cancelled it. This is a configured limit, not infrastructure failure - the step either needs more time or is hanging.
What this error means
A step is cancelled mid-run with a message that the timeout was reached, even though it had not finished.
##[error]The action 'Run integration tests' has timed out after 10 minutes.
##[error]The operation was canceled.Diagnose it: print the context before you change anything
Most workflow-expression bugs are not syntax errors, they are an expression reading something that is empty. GitHub resolves a missing property to an empty string instead of failing the run, so a wrong reference looks like a logic bug rather than a mistake. Dump the contexts first and you will usually see the answer immediately.
- name: Dump contexts
run: |
echo '--- github ---' ; echo '${{ toJSON(github) }}'
echo '--- needs ---' ; echo '${{ toJSON(needs) }}'
echo '--- steps ---' ; echo '${{ toJSON(steps) }}'
echo '--- matrix ---' ; echo '${{ toJSON(matrix) }}'
echo '--- inputs ---' ; echo '${{ toJSON(inputs) }}'Check the context is allowed where you used it
Contexts are not available everywhere. The same expression can be valid in a step if and invalid in a job if, which is why an expression that works in one workflow fails when moved.
| Where you wrote it | Contexts available there |
|---|---|
run-name | github, inputs, vars |
concurrency | github, inputs, vars |
Top-level env | github, secrets, inputs, vars |
jobs.<id>.if | github, needs, vars, inputs |
jobs.<id>.steps.if | github, needs, strategy, matrix, job, runner, env, vars, steps, inputs |
jobs.<id>.outputs | Full access, including secrets |
Reusable workflow outputs | github, jobs, vars, inputs |
Common causes
Limit lower than the real runtime
timeout-minutes was set tighter than the step actually needs, so a healthy run gets cut off.
Step is hanging
A process waits on input, a network call, or a service that never responds, so it never completes within the limit.
How to fix it
Right-size the timeout or fix the hang
- Measure the step's normal duration and set timeout-minutes with headroom.
- If it hangs, add internal timeouts to the hanging command (for example a test or curl timeout).
- Re-run.
- name: Integration tests
timeout-minutes: 20
run: npm run test:integration -- --testTimeout=60000Catch it before it reaches CI
Every failure in this cluster is statically detectable. actionlint parses workflow expressions, checks context availability against the same rules above, and validates needs references, so these bugs never need to cost you a run.
# one-off
docker run --rm -v "$(pwd):/repo" --workdir /repo rhysd/actionlint:latest -color
# as a job, before anything expensive runs
- uses: actions/checkout@v4
- run: |
bash <(curl -s https://raw.githubusercontent.com/rhysd/actionlint/main/scripts/download-actionlint.bash)
./actionlint -colorHow to prevent it
- Set timeout-minutes with headroom over observed runtimes.
- Add command-level timeouts so hangs fail fast with a clear cause.