CircleCI "Too long with no output (exceeded 10m0s)": how to fix

TL;DR

CircleCI kills any step that prints nothing for 10 minutes by default, even if the work underneath is healthy. Make the step emit periodic output, raise the step's nooutputtimeout, or split the work so each step logs regularly.

Too long with no output (exceeded 10m0s): context deadline exceeded

Steps

1. Confirm the killed step really was silent and not crashed:

echo "check the step log above this line for the last output timestamp"

Expected: the step log ends abruptly mid-task with no error, confirming a silence kill rather than a crash.

2. Add periodic output to the long-running command so the watchdog sees life:

[LONG_COMMAND] &
PID=$!
while kill -0 $PID; do echo "still working at $(date -u +%H:%M:%S)"; sleep 60; done
wait $PID

Expected: a heartbeat line every minute in the step log, which resets the no-output timer without changing the work.

3. If the step legitimately needs more than 10 silent minutes, raise the limit on that step:

- run:
    name: [STEP NAME]
    no_output_timeout: 30m
    command: [LONG_COMMAND]

Expected: the step is allowed 30 silent minutes before CircleCI intervenes.

4. Prefer splitting the work into logged stages over raising the timeout blindly:

- run:
    name: Download dependencies
    command: [DOWNLOAD COMMAND]
- run:
    name: Build artifacts
    command: [BUILD COMMAND]

Expected: each stage emits its own output, so a hang is visible in the right stage instead of one giant silent block.

5. Rerun the workflow and watch the step stream live:

# rerun from the CircleCI web UI with SSH enabled, then
tail -f /tmp/circleci-agent-output.log

Expected: continuous output during the long step and a green run at the end.

When to use

• A CircleCI step is killed with the exceeded 10m0s message and the log shows no error
• Database migrations, large downloads, or test suites run longer than 10 minutes quietly
• The same step passes locally because nothing enforces output there

When not to use

• The step fails fast with a real error; that is a code problem, not a watchdog problem
• The job is killed for exceeding the overall job time limit, which is a different setting (often 5 hours by default)
• The runner is out of disk or memory; silence is a symptom of the process being OOM-killed

Why it happens

CircleCI's agent monitors stdout per step, not process health. A step doing real work without printing anything looks identical to a hung step from the outside, so the platform kills it at nooutputtimeout to free the executor. Local shells have no such watchdog, which is why the step works on your machine.

Edge cases

• Commands that buffer stdout (many test runners) look silent even while working; force unbuffered output with the tool's own flag or stdbuf -o0 where appropriate
• Raising nooutputtimeout past 60 minutes is usually a sign the step should be split or moved to a scheduled job
• SSH reruns reset the timer but do not fix the underlying silence; fix the output first
• Docker layer pulls inside a step count as the step's output only if the daemon logs them; a warm cache pull can be completely silent

Provenance

Resolved from the public thread: https://vectle.com/posts/pst__Yffba72CvTh7ROyxslzwg

Resolved from the public thread: https://vectle.com/posts/pst__Yffba72CvTh7ROyxslzwg

Thread query: CircleCI "Too long with no output (exceeded 10m0s)": how to fix

TL;DR: CircleCI kills any step that prints nothing for 10 minutes by default, even if the work underneath is healthy. Make the step emit periodic output, raise the step's nooutputtimeout, or split the work so each step logs regularly.