GitHub Actions cancellation lacks configurable grace period for SIGTERM handling

No configurable grace period exists

GitHub Actions does not expose a setting to delay forceful termination after a cancellation request. timeout-minutes and concurrency.cancel-in-progress: true determine whether and when a job is canceled; neither adds a pre-termination wait, and there is no documented minimum window between SIGTERM and SIGKILL.

Confirmed behavior

• On cancellation, the runner terminates the current process tree; the executing step is interrupted immediately.
• if: cancelled() applies to subsequent steps, not to the step currently running, so it cannot replace in-step signal handling.
• Reusable workflows and composite actions inherit the same termination sequence and cannot override it.
• GitHub-hosted runners cap jobs at six hours; after that limit, cancellation is unavoidable.

Likely explanation (unverified interval)

The runner or Actions service ends the job process on cancel. GitHub does not publish the SIGTERM-to-SIGKILL interval, and it may vary by runner image, runner version, or service behavior. Treat any observed interval as incidental, not a contract.

Steps for this case

1. In the long-running step, trap SIGTERM in the shell or language runtime and perform cleanup before exiting: flush buffers, release distributed locks, and notify external systems.
2. Do not rely on if: cancelled() for cleanup of the interrupted step; use it only for later steps that should run after cancellation.
3. On self-hosted runners, do not ignore termination signals to extend the window; the control plane can still mark the job failed, and ignoring signals may orphan processes or hold locks.

Verification

Run a controlled cancel test on the runner image you use. This example writes signal receipt and start timestamps to a file:

#!/usr/bin/env bash
set -u
cleanup() {
  echo "SIGTERM received at $(date -u +%s.%N)" > term-times.txt
  # insert your flush or lock-release logic here
  exit 143
}
trap cleanup TERM
echo "started at $(date -u +%s.%N)" > term-times.txt
sleep 3600

Cancel the job through the UI or concurrency.cancel-in-progress, upload term-times.txt as an artifact, and compare the timestamps. Repeat on each runner image you support; differences are image-specific behavior, not a guaranteed grace period.

Missing diagnostic detail: which runner image and runner application version are you using? The interval may differ across images and versions, so that detail determines whether the observed behavior is worth repeating elsewhere.