You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm investigating an unexpected shutdown of a GitHub-hosted Ubuntu runner during an active GitHub Actions job.
Environment
Runner: GitHub-hosted ubuntu-24.04
Runner version: 2.338.0
Runner image version: 20261012.334.1
Workflow trigger: workflow_dispatch
Job timeout: 25 minutes
Step timeout: 23 minutes
Concurrency: cancel-in-progress: false
What happened
The workflow successfully reached a Docker container execution stage and started npm ci --offline.
Approximately 10 seconds after npm started, the job reported:
The runner has received a shutdown signal.
This can happen when the runner service is stopped,
or a manually started runner is canceled.
Process completed with exit code 143.
The exit code 143 belongs to the host workflow step. No npm exit code was captured.
The last available container heartbeat showed no OOM kill, but the final container state could not be verified.
The job concluded as failure, not cancelled.
A subsequent artifact-upload step configured with if: always() was skipped.
What I investigated
I reviewed GitHub Actions Runner v2.338.0 source code and found that runner shutdown can bypass step-condition evaluation, explaining why an always() step may be skipped.
However, this does not identify what initiated the shutdown.
The job had not reached its configured timeouts, and I found no evidence of a competing workflow cancellation.
Questions
What conditions can cause a GitHub-hosted runner to receive a shutdown signal while a job is actively running?
Is there a way to distinguish user cancellation, control-plane termination, runner service shutdown, and infrastructure interruption?
Can billing enforcement or ephemeral-runner lifecycle events produce this behavior?
What diagnostic information is available to users when the runner shuts down before artifact upload?
Are there recommended practices for preserving minimal diagnostic evidence during an unexpected runner shutdown?
I have not retried the workflow because I would first like to understand the possible causes and the appropriate diagnostic approach.
Any guidance from the community would be appreciated. Thank you!
ActionsBuild, test, and automate your deployment pipeline with world-class CI/CDQuestionAsk and answer questions about GitHub features and usageActions RunnerFor issues and discussions related to the Actions Runner projectWelcome 🎉Used to greet and highlight first-time discussion participants. Welcome to the community!source:uiDiscussions created via Community GitHub templates
1 participant
Heading
Bold
Italic
Quote
Code
Link
Numbered list
Unordered list
Task list
Attach files
Mention
Reference
Menu
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
🏷️ Discussion Type
Question
💬 Feature/Topic Area
Actions Runner
Discussion Details
Hello GitHub Community,
I'm investigating an unexpected shutdown of a GitHub-hosted Ubuntu runner during an active GitHub Actions job.
Environment
ubuntu-24.042.338.020261012.334.1workflow_dispatchcancel-in-progress: falseWhat happened
The workflow successfully reached a Docker container execution stage and started
npm ci --offline.Approximately 10 seconds after npm started, the job reported:
The exit code 143 belongs to the host workflow step. No npm exit code was captured.
The last available container heartbeat showed no OOM kill, but the final container state could not be verified.
The job concluded as
failure, notcancelled.A subsequent artifact-upload step configured with
if: always()was skipped.What I investigated
I reviewed GitHub Actions Runner v2.338.0 source code and found that runner shutdown can bypass step-condition evaluation, explaining why an
always()step may be skipped.However, this does not identify what initiated the shutdown.
The job had not reached its configured timeouts, and I found no evidence of a competing workflow cancellation.
Questions
I have not retried the workflow because I would first like to understand the possible causes and the appropriate diagnostic approach.
Any guidance from the community would be appreciated. Thank you!
All reactions