CircleCI Step Timed Out vs No-Output - Fix Long-Running Steps

By Daniel Zoghalchali·Latchkey

A step is cut off for taking too long overall - distinct from the "no output for 10 minutes" cancel. A transient slow dependency, an overloaded external service, or a long-tail run can trip a runtime/job time limit and usually clears on retry.

What this error means

A step that is actively producing output still gets terminated for exceeding a time budget, often after a slow network call or a heavy external dependency. Re-running frequently passes because the slowness was transient.

Step exceeded the configured time limit and was terminated.
# emitting output the whole time, but ran past the budget

Common causes

Transient slowness in a dependency or service

A slow package mirror, a backed-up external API, or contended CI capacity makes a normally-fast step run long enough to hit the limit. It is intermittent, not a code bug.

A time budget that is too tight for the step

A no_output_timeout or overall budget set lower than the step’s real worst-case runtime trips on slow runs even though the step is healthy.

A real long-tail or hang

Occasionally the step is genuinely stuck (a retry storm, a lock). Then the timeout is correct and the underlying wait must be fixed.

How to fix it

Give slow-but-healthy steps a realistic budget

- run:
    name: Integration suite
    command: ./run-integration.sh
    no_output_timeout: 30m

Retry transient slowness and harden externals

1. Re-run the workflow first - a one-off slow run usually passes.
2. Wrap flaky external calls in a bounded retry with backoff.
3. Cache heavy downloads so a slow mirror cannot dominate the step.

How to prevent it

• Set time budgets from real worst-case runtime, with margin.
• Add bounded retries/backoff around flaky external dependencies.
• Cache slow downloads so transient mirror slowness does not trip limits.

Frequently asked questions

Related guides

References

• GitHub Actions documentation