missing-timeout-minutes
Detects non-matrix jobs of interest that do not define job-level timeout-minutes.
Why this rule exists:
- without job-level
timeout-minutes, the job falls back to the platform default timeout instead of a repo-specific limit - hung or degraded jobs can keep consuming runners much longer than intended
- on release-like jobs, that can also delay follow-up publishing, locking, or finalize paths longer than intended
- on agentic or AI-assisted jobs, hangs can also burn runner time for a long time before anyone notices
- step-level timeouts help, but they do not put one ceiling around the whole job
Current MVP heuristic:
- the workflow is not manual-only
- the workflow is triggered by
pushorpull_request - the workflow has a relatively small number of jobs, so job-level timeout ownership is clear
- the job looks heavy from its commands or name, or it is agentic enough to justify a job-level timeout
- the job is not a matrix job
- the job does not define job-level
timeout-minutes
Typical remediation:
- set a job-level timeout that matches the expected runtime and failure budget
- leave the timeout generous enough for legitimate long-running runs
What job-level timeout-minutes missing usually means in practice:
- the job does not fail fast when it hangs
- the run is terminated only when the platform-level timeout is reached
- a broken external dependency, network wait, deadlock, or stalled test process can sit on a runner longer than you intended
- even if one heavy step has its own timeout, setup, download, upload, and cleanup steps can still run without a single job-wide ceiling