CI job or pipeline exceeded time limit

What this failure means

The CI job ran past its configured time limit and was killed by the CI system. This is a hard stop — no further steps ran.

Symptoms

Faultline looks for one or more of these log fragments:

Job's timeout exceeded
execution timeout
timeout was exceeded
execution took longer than
exceeded the maximum execution time
build timed out
pipeline timed out
timed out after

Diagnosis

The CI job ran past its configured time limit and was killed by the CI system. This is a hard stop — no further steps ran.

Fix steps

1. Check the last progressing log line before the timeout killed the job — this tells you whether something was still working or had silently hung.

2. Wrap suspect commands with an explicit timeout so the failure is fast and obvious rather than silent:

   timeout 120 <command>          # exits non-zero if it exceeds 120 s
   

3. Remove interactive prompts and TTY-only behaviour from setup commands: --yes, --non-interactive, CI=true, DEBIAN_FRONTEND=noninteractive.

4. For Go test hangs: send SIGQUIT to get a goroutine dump showing exactly which goroutine is blocked:

   kill -QUIT $(pgrep 'test.timeout')
   # or set GOTRACEBACK=all before the test run
   

   For Node/Jest hangs: use --detectOpenHandles to find resource leaks.

5. Cache dependency downloads and split long-running stages into smaller jobs before increasing the global timeout limit.

6. Increase the CI timeout only after identifying a bounded slow path that legitimately needs more time — raising it blindly hides regressions.

Validation

• Re-run the failing step with timeout <N> wrapper and confirm it completes within the expected window.
• Confirm no goroutine dump, --detectOpenHandles, or hang indicator appears in the output.

Why it matters

Common causes: a test is stuck waiting on a network call or socket, a build step hangs on user input, a dependency download stalls, or the workload genuinely takes longer than the limit allows.

Prevention

• Set per-step timeouts in addition to the job-level timeout so the failing command is obvious.
• Add explicit timeout or watchdog settings to test runners, network-heavy scripts, and deploy commands.
• Emit periodic progress logs or heartbeats for long-running steps so silent hangs are easy to distinguish from slow but healthy work.
• Track median and p95 job duration by pipeline so regressions are visible before they start hitting the hard limit.

Try it locally

timeout 120 <command>
timeout 120 <command>

How Faultline detects it

Use faultline explain pipeline-timeout to see the full playbook.

faultline analyze build.log
faultline explain pipeline-timeout

Generated from playbooks/bundled/log/ci/pipeline-timeout.yaml. Do not edit directly.