## 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 no_output_timeout, or split the work so each step logs regularly.

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

## Steps

1. Confirm the killed step really was silent and not crashed:
```bash
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:
```bash
[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:
```yaml
- 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:
```yaml
- 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:
```bash
# 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 no_output_timeout 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 no_output_timeout 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