Skip to content
Latchkey

CI "command timed out after Nm"

A command wrapped in a timeout (or a tool with its own deadline) ran longer than allowed and was killed. The cause is either a transient slowdown or a genuine hang.

What this error means

A step reports command timed out after 5m (or similar) and exits non-zero. A re-run completes when the slowness was a one-off; a real hang times out every run.

shell
command timed out after 5m0s
##[error] Process completed with exit code 124.

Common causes

A transient slowdown exceeded the timeout

A slow network fetch or a briefly busy service pushed a normal command past its deadline.

A genuine hang or deadlock

A command waiting on something that never arrives runs until the timeout kills it (exit 124).

How to fix it

Retry transient timeouts

A bounded retry covers a one-off slowdown.

shell
for i in 1 2 3; do
  timeout 300 ./flaky-step.sh && break
  sleep $((i*5))
done

Fix or accommodate slow work

  1. If it hangs every time, debug the deadlock or missing input.
  2. Raise the timeout if the work is legitimately longer.
  3. Speed up the command (cache, parallelism) to fit the budget.

How to prevent it

  • Choose timeouts that cover realistic runtime.
  • Distinguish hang (always) from slow (sometimes).
  • For transient infra slowdowns, managed runners detect the mechanical blip and automatically retry, so a one-off timeout does not fail the build.

Frequently asked questions

What causes "command timed out"?
A slow network fetch or a briefly busy service pushed a normal command past its deadline.
How do I fix command timed out?
A bounded retry covers a one-off slowdown.
Can Latchkey fix this automatically?
Yes. Latchkey runs your GitHub Actions on managed runners that detect this failure, apply the fix, and retry the job automatically - self-healing is on by default.

Related guides

References

Latchkey auto-heals failures like this one - detected, fixed, and retried without you. Start free → 30-day trial · No credit card