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.
Top comments (2)
Your point about always-red scheduled workflows becoming background noise feels right, especially once the inbox has trained people to ignore the whole signal. When one of those failures is intermittent instead of permanently broken, how do you figure out which commit first introduced the flake today, if at all?
Honestly, most of the time you can't, at least not from a single run. A hard break is easy: first red run, there's your commit. A flake passes whenever it feels like it, so no individual run proves anything.
The trick is thinking in failure rate instead of pass/fail. If you've got run history, gh run list --workflow="X" --json headSha,conclusion --limit 200, group by SHA, and look for where the pass rate shifts. Crude but free. The catch with scheduled workflows is the history is sparse (each run hits whatever main was that day), so you need a decent pile of runs before the shift means anything.
If you actually need the commit, git bisect still works, you just have to make "good" mean "passed 20 times in a row":
git bisect run sh -c 'for i in $(seq 20); do npm test || exit 1; done'
Expensive, but a single-run bisect on a flake just chases ghosts.
And sometimes the real answer is "not enough data yet." Below a certain run volume, any tool that names a commit is guessing. I'm building rate-shift detection into the monitoring side of the scanner right now, and the hard part isn't the detection, it's knowing when to shut up and say "can't tell."