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

trpc has a scheduled workflow called "Lock Issues & PRs." Its own scorecard shows it failing on almost every run. It is still scheduled, still running, still red. trpc ships excellent software, which is exactly 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"). I scanned 35 popular open-source repos and 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.

First, those emails are routine. You get them for flaky reruns and transient blips too, so you filter them out. Second, a workflow that is always red stops reading as a signal. It is just how that row looks now.

I did exactly this on my own project. GitHub emailed me that a workflow had failed. The next day it emailed again. I saw it, told myself I would fix it tomorrow, and promptly forgot. It was my nightly database backup, quietly broken the whole time, and I only caught it when a failure-rate number crept up where I would notice.

An always-red workflow is not 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

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.

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.

I built a free scanner that flags always-failing workflows (and other CI waste) for any public repo, no install required: gitspider.com/scan. The full writeup with the config fixes lives here.