Hosted ubuntu-latest jobs killed ~80s after start — no step failure, exit 143 when a step is running (25% of runs since Jul 30)

[dosxnjos]

Summary

Since July 30, 2026, roughly a quarter of our scheduled jobs on ubuntu-latest are killed in the first ~90 seconds, before any workflow step reports a failure. Runs that survive that window complete normally in 13–15 minutes. There is no middle ground — we have no "slow" runs, only killed-early or normal.

Measurements

100 most recent runs of one workflow. Job duration measured startedAt→completedAt (not run createdAt→updatedAt, which sums retries and inflates everything).

window	killed early	total runs
Jul 25–29	0	36
Jul 30 – Aug 3	16	64 (25%)

Durations of the 16 kills, in seconds:

75 76 77 77 79 80 86 91 92 92 93 96 | 136 165 216 231

11 of 16 died between 75 and 96 seconds with no step marked as failed — the job dies during setup, before any of our steps report. The remaining 5 died between 136 and 231 s, and there the failed step is simply whichever one happened to be running; it varies between attempts of the same run.

Two distinct annotation signatures, same underlying event

1. The runner has received a shutdown signal… and/or The operation was canceled. — with run conclusion failure (nobody cancelled anything).
2. When a step is executing: only Process completed with exit code 143 (SIGTERM), with neither of the above.

Signature 2 is worth flagging on its own: any retry automation keyed on the "shutdown signal" / "was canceled" strings will silently miss it. Ours did, and runs sat unretried until someone noticed by hand.

What we ruled out

• Our own timeouts — step timeouts are 15/25 min and the job timeout is 90 min; kills happen at ~1–2 min.
• OOM — that surfaces as 137 (SIGKILL); we consistently see 143.
• Manual cancellation — that concludes cancelled; all of these conclude failure.
• A specific step or tool — the step varies, and the kill time tracks the clock, not the work being done.

Other observations

• No time-of-day pattern — spread across all 24 hours.
• Scheduled/dispatched runs are affected at a similar rate; nothing in our workflow changed on July 30.

Environment

ubuntu-latest, GitHub-hosted, private repository, single job, typical successful runtime 13–15 min.

Question

Is this a known reclamation/recycling behaviour on hosted runners, and is there anything on our side that can make a job survive that first window? Run IDs available on request (private repo).

[github-actions[bot]]

Thank you for your interest in contributing to our community! We currently only accept discussions created through the GitHub UI using our provided discussion templates. Please re-submit your discussion by navigating to the appropriate category and using the template provided.

This discussion has been closed because it was not submitted through the expected format. If you believe this was a mistake, please reach out to the maintainers.