GitHub Actions cancellation and timeout cleanup behavior needs diagnosis

Direct answer

No, you cannot rely on signal handlers completing, and the grace period is not anchored to the moment timeout-minutes expires. Both settings are job-level only; there is no native per-step deadline, and cancel-timeout-minutes bounds runner-side cleanup after the runner observes and acts on a cancellation.

1. Does cancel-timeout-minutes apply equally to timeout expiry and manual cancellation?

Confirmed: timeout-minutes and cancel-timeout-minutes are job-level settings. When a job reaches its timeout, GitHub Actions processes that as a cancellation. Expected behavior to verify: the same cancel-timeout-minutes grace window applies to both manual cancellation and timeout expiry once the runner begins cancellation. Important caveat: the clock starts when the runner observes and acts on the cancellation, not when timeout-minutes is reached. Any service-to-runner latency is outside the grace period.

2. Can cleanup rely on EXIT, INT, or TERM handlers?

Confirmed: there is no native per-step timeout, and cancel-timeout-minutes does not guarantee that final steps or always() blocks complete if the runner force-kills the job. Likely: neither manual cancellation nor timeout expiry guarantees that EXIT, INT, or TERM handlers run to completion. After the grace period, the runner may terminate the step process or process group. The exact signal sequence and trap behavior can vary by runner version, operating system, shell, and pinned image revision. Self-hosted runners are excluded from this scope and may behave differently.

Practical cleanup contract

Treat signal-handler output as best-effort evidence, not a contract. Make cleanup idempotent and tolerant of hard termination. Do not assume background or detached child processes receive the same signal or die with the step shell; reparented children may survive.

Verification on a pinned runner image

Use a disposable workflow on an explicitly pinned ubuntu-latest image revision to compare both paths:

1. Create two identical jobs with the same timeout-minutes and cancel-timeout-minutes.
2. In each step, install trap handlers for INT, TERM, and EXIT that write timestamped messages to stdout and a file.
3. Start a child process that logs its own state, then sleep.
4. Manually cancel one job after a short run; let the other reach timeout-minutes.
5. Inspect job logs for trap messages, job status, step outcome, elapsed time, and whether the child log stopped.

Compare manual cancellation against timeout expiry for identical trap output, completion within cancel-timeout-minutes, and any hard-kill indicators such as a missing EXIT message or process-group termination. Verify against the runner release notes for the exact pinned image revision, because signal-handling guarantees may change between runner versions.

Missing diagnostic detail

No single missing detail changes this recommendation. The exact runner image revision or release affects only which signals you observe in verification, not the cleanup design.