← All guides

The GitHub Actions workflow that's been failing for weeks (and how to find it)

trpc has a scheduled workflow called "Lock Issues & PRs." Its own scorecard says it is failing almost every run. It is still scheduled, still running, still red. trpc ships excellent software, which is the point: if a project this careful has a workflow that has been red for ages, the rest of us almost certainly do too.

It is not a one-off. drizzle-orm has one ("Unpublish release"). cal.com has one ("PR Update"). When I scanned 35 popular open-source repos, the same thing kept turning up: a scheduled workflow that fails on nearly every run, quietly, for a long time.

Why nobody notices

GitHub does email you when a scheduled workflow fails, so how do these survive? Two reasons. Those emails are routine, you get them for flaky reruns and transient blips too, so you filter them. And a workflow that is always red stops reading as a signal, it is just how that row looks now. I did exactly this to my own nightly database backup (I wrote about it here): saw the email, told myself I would fix it tomorrow, forgot.

An always-red workflow isn't free

It burns minutes every run to produce nothing but a red X. Worse, it trains you to ignore the failure that actually matters, the day a real one lands in the same inbox you have learned to skim past.

How to find yours

Open your Actions tab and look at the scheduled workflows, the cron-triggered ones nobody watches. If the last several runs are all red, you found one. From the CLI:

gh run list --workflow="Lock Issues & PRs" --status=failure

GitSpider flags always-failing workflows automatically, so you do not have to go hunting.

What to do about it

Two honest options: fix it, or if the workflow is genuinely abandoned, turn it off. Do not leave it scheduled and red. Disable it from the CLI:

gh workflow disable "Lock Issues & PRs"

Or drop the schedule trigger from the workflow file if it should not run on a timer at all. A disabled workflow is honest. A red one you have trained yourself to ignore is a liability.

These hide across however many workflow files you have, which is exactly why nobody sits down and fixes them. Point GitSpider at your repo and it flags which patterns apply, with the fix for each.

Scan your repo free