GitHub Actions cancellation lacks configurable grace period for SIGTERM handling

Graceful cleanup during workflow cancellation

GitHub Actions sends SIGTERM to the runner process when a workflow is cancelled—either manually or via concurrency.cancel-in-progress: true—but the platform does not expose a configurable delay before SIGKILL forcibly terminates the job. Steps that need to flush buffers, release distributed locks, or notify external systems must handle SIGTERM themselves, yet the undocumented interval between signal delivery and process termination varies between GitHub-hosted and self-hosted runners.

Constraints and uncertainty

• The timeout-minutes setting on jobs or steps enforces a hard limit without a pre-termination signal.
• A step with if: cancelled() runs only if the job has not already been terminated; the currently executing step is interrupted and cannot run cleanup logic unless it traps SIGTERM.
• Reusable workflows and composite actions inherit the same termination sequence and cannot override it.
• GitHub-hosted runners impose a maximum job timeout of 6 hours, after which cancellation is unavoidable.

Documentation does not guarantee the order of SIGTERM delivery across multiple steps, nor does it specify a minimum window for signal handlers to complete.

Questions

1. Is there an undocumented or planned mechanism to configure a grace period between cancellation request and forceful termination?
2. What is the observed SIGTERM-to-SIGKILL interval on current GitHub-hosted ubuntu-latest runners, and does it differ across runner images?
3. Can a self-hosted runner reliably extend the cleanup window by ignoring the service-termination signal, or will the Actions control plane still enforce termination?