GitHub's Abuse Filter Locked Out Its Own Customers for 16 Hours. Then Actions Fell Over Again. This Is the Precision Problem We Keep Warning About.

If you run anything that blocks bad traffic — a WAF, rate limits, IP reputation, geo-fencing, an abuse filter — the most important number you are not looking at is your false-positive rate. GitHub spent the last day proving why, and it is a lesson worth stealing before it happens to you.

Here is what happened, per GitHub's own status page. Two separate incidents, back to back.

Incident one: the defense became the outage

Starting the evening of July 23 (around 18:45 UTC) and running until mid-morning July 24 (about 11:19 UTC) — roughly sixteen hours — GitHub pushed an abuse-mitigation update that incorrectly blocked legitimate customers. Specifically, users whose traffic was routed through GitHub's Central Europe and South America edge locations were locked out of GitHub.com. Not attackers. Paying, legitimate developers, blocked from the platform their work lives on, because a rule meant to stop abuse could not tell them apart from the abuse.

That sentence is the entire discipline of edge defense, compressed. An abuse filter has exactly one hard job: separate the malicious request from the legitimate one. When it can't, and it errs toward blocking, it stops being a defense and starts being your incident. Sixteen hours of legitimate users in two whole regions couldn't reach GitHub — and the cause wasn't an attacker. It was GitHub's own protection, tuned too hot, with nothing catching the collateral damage before it shipped.

Incident two: the afternoon pile-on

Then, this afternoon around 16:17 UTC, GitHub began investigating degraded performance across API requests and Issues, followed minutes later by timeouts to several services. Actions, Pages, Copilot, and Pull Requests all degraded in the same window. For a platform that sits underneath the world's CI/CD, "Actions is degraded" is not a status-page footnote — it is every deploy pipeline on Earth holding its breath.

Two incidents in a day, one of them self-inflicted, is why "GitHub had another hiccup" has quietly become a recurring sentence. We wrote three weeks ago about a free GitHub Actions certificate that expired and killed self-hosted runners, and about the replacement cert that sat valid and unused for 31 days. The through-line isn't incompetence — GitHub operates at a scale almost nobody else touches. The through-line is that the hardest problems in running infrastructure are not the exotic attacks; they are the boring, self-inflicted ones: an expired cert, an over-eager abuse rule, a config that was fine in staging.

Why this is our lane, specifically

We run edge blocking for a living — a Cloudflare Worker that pulls our threat feed and blocks malicious IPs, honeypot canaries, an autonomous decision layer. Blocking is the easy half. The hard half, the half that took us the longest to get right, is not blocking the wrong thing, and it is built on three habits GitHub's incident is a textbook argument for:

Fail open, not closed. When our suppression data is unavailable or a check is uncertain, our feed keeps serving and the edge keeps letting legitimate traffic through — we would rather momentarily miss a block than momentarily wall off a real user. An abuse system that fails toward "block everyone in this region" is a system whose failure mode is an outage. Decide which way yours fails before it has to.

Gate your own confidence. We run every high-confidence block-candidate past an independent signal (a global sensor network) specifically to catch the cases where we are wrong — where the thing we flagged as malicious is actually a known-good scanner or business infrastructure. That precision gate exists for one reason: to stop us from doing to a customer exactly what GitHub just did to two regions. If your blocking has no counterweight that can say "wait, that one's legitimate," you don't have a defense, you have a loaded gun pointed at your own users.

Watch the false-positive rate like it's a KPI, because it is. True-positive metrics — threats blocked — feel great and tell you nothing about who you hurt. The number that predicts a GitHub-shaped morning is the one nobody frames on the dashboard: how often did we block someone we shouldn't have. This morning, coincidentally, our own hunter flagged a college student's empty repository as an "Android RAT" on a name match. We caught it and pulled it before it reached the feed — because catching our own false positives is a standing job, not an afterthought. That is the same muscle GitHub's abuse rule needed and didn't have.

The takeaway

Roll out an abuse-mitigation change the way you'd roll out anything that can hurt production: staged, with a fast rollback, and with a metric watching for legitimate users suddenly disappearing from a region. Blocking harder is not a security win if the thing you blocked was your customer. The world's largest code host just spent sixteen hours learning that in public. The cheap version of that lesson is reading about it here and going to check what your own filters do when they're not sure.

---

How do AI models see YOUR brand?

AIPM has audited 250+ domains. 15 seconds. Free while still in beta.

Audit your site now → aipmsec.com