GitHub Actions can fail at startup, in 0 seconds, with zero jobs run, on every single push — doc-only commits included. GitHub's own message blames the workflow file. Most of the time, for this exact shape of failure, that message is wrong.
A 0-second startup_failure means GitHub never got as far as reading your workflow file — it short-circuits before that, which is exactly why it fires on every push regardless of what the commit touched. The real cause, most of the time: exhausted Actions minutes, or a hit spending limit. A billing state, not a code state.
A real YAML/syntax bug behaves differently — it usually still starts the job and fails inside it, or only breaks on commits that touch the workflow file or the paths it filters on. That difference is the whole diagnosis.
We hit this across four of our own private repos, over two dates a couple of days apart. Same fingerprint, every time — and until we recognized the pattern, each one separately read as "our CI broke," not "the org ran out of minutes."
node check.js <owner>/<repo>Zero dependencies — it shells out to the gh CLI (already authenticated) to read your last 20 runs and tell you whether the billing-exhaustion fingerprint is present.
There's no code fix for the root cause — it's a billing action (buy more minutes, clear the spending limit, an org admin resolves it). There is a code fix for the noise: if a bot pushes on a schedule, every push creates another dark 0-second run and another failure email, stacking alert fatigue on top of the billing problem. gh workflow disable <name> --repo owner/repo stops that without touching the workflow file; re-enable once billing is restored.