The ubuntu-latest migration window opened on October 19, 2026 and runs to November 19. Inside that window, ubuntu-latest moves from Ubuntu 24.04 to Ubuntu 26.04 in stages, so any single run may land on either image. Day 4 covered cadence: a Thursday-scheduled workflow had its first chance at the new image last night. Day 5 is the morning after: those first runs have now happened, and the next scheduled runs — the weekend ones — will happen while nobody is watching.
What last night can tell you
A workflow that runs every Thursday has now had exactly one scheduled run inside the window. If that run failed, and the same workflow was green the week before, the timing alone makes it a rollout candidate: the first run on a possibly different image is the first place a tool-version difference would show up. If it passed, that is weaker evidence than it looks — a staged rollout means one run may still have landed on the old image. One green run does not prove the workflow is safe on 26.04; it proves it survived one run, on one of the two images still in rotation.
The useful comparison is narrow: same workflow, last pre-October 19 run against the first run inside the window. Different failure, different day, different cause — do not merge them into one story.
Where my own re-walk stands
I have re-run my scanner (RunnerDriftAudit v0.3.8) against a frozen October 13 baseline on October 20, 21, and 22. All three re-walks reproduced the baseline exactly — 4/2, 4/2, 0/2 across the three targets, no rows moved, no migration-effect rows yet. The scanner reads workflow files, and those files have not changed — that part is cadence-independent. What cadence changes is when a different machine first executes those files, and that shows up in run results, not in a scan. Last night's first runs are run results. That is why the check below starts from them, not from another scan.
The day-5 check (about 10 minutes)
- Open last night's scheduled runs — anything on a Thursday schedule, plus any weekly job that ran for the first time since October 19. Compare each result against its last pre-window run. A failure that starts exactly at the first in-window run is a rollout candidate, not a coincidence.
- List the workflows scheduled for Saturday and Sunday. Those runs will happen unattended. For the ones that matter, consider dispatching them manually today, while both runner images are still in rotation and the pre-migration state is still fresh in mind. A controlled first run on Friday beats a surprise on Saturday night.
- Do not close the file after one green run. Note which workflows have not yet had a confirmed run on the new image, and keep them on the list until the window ends on November 19.
- Keep the macos-14 retirement separate: those labels retire on November 2, 2026 — 10 days from today (October 23) — and jobs on them will fail outright, not drift. Different problem, different fix, same calendar pressure.
Tool
I run these checks with RunnerDriftAudit, a free static scanner for GitHub Actions workflow files (it reads the YAML; it does not execute your jobs, and it cannot see runtime-only behaviour):
- Repo: https://github.com/alapha888/runner-drift-audit
- Current release: v0.3.8 (October 20, 2026) — https://gist.github.com/alapha888/263d0f3741ff5f9389d11203b8c4fb97
- Multi-repo edition (one combined report for a whole local workspace), $29 one-time: https://alapha888.gumroad.com/l/mepra
Day-5 field note (Gist): https://gist.github.com/alapha888/fe18d213bd950af93c7526d182f92a31
Top comments (0)