DEV Community: John Santias

GitHub has had 257 incidents in 12 months. Here's what that means for your CI pipelines

John Santias — Wed, 27 May 2026 09:36:59 +0000

I've been building a tool that watches GitHub CI pipelines and surfaces failures every morning. While building it I started paying closer attention to GitHub's own reliability track record.
The numbers are worse than I expected.

Between May 2025 and April 2026, GitHub experienced 257 incidents including 48 major outages. GitHub Actions alone suffered 57 outages in that period. GitHub's CTO attributed the root cause to explosive growth from agentic AI workflows demanding 30 times the platform's designed capacity.

That's roughly five incidents a week, every week, for a year.

The problem this creates for developers

When your CI pipeline fails, you now have two possible explanations. Your code broke something, or GitHub is having an incident. Without visibility into both, you're flying blind.

On May 15, 2026, GitHub Actions experienced a degradation where at peak impact 42% of Actions runs failed. Any developer who woke up that morning and saw CI failures across their repos would reasonably start debugging their own code, before eventually realising it was a platform issue, not their problem.

That's hours of wasted debugging time across thousands of developers simultaneously.

The situation has gotten bad enough that Mitchell Hashimoto, co-founder of HashiCorp, announced his Ghostty terminal emulator project, which has over 52,000 GitHub stars, would be leaving the platform, writing that GitHub "is no longer a place for serious work."

What you can actually do about it

You probably can't move off GitHub today. Most teams can't. But you can change how you relate to the noise it generates.

A few things that help:

Check the GitHub status page before debugging CI failures (githubstatus.com). It sounds obvious but most developers don't do it automatically.
Group your CI failures before investigating. Three failures on the same repo in an hour are probably one problem, not three. And if that problem started at the same time GitHub had a known incident, that's your answer.
Separate platform failures from code failures in how you track them. They require different responses and different people. I built Dailix to solve the grouping and prioritisation problem for myself - one email every morning that tells me what's actually broken versus what's noise. It doesn't solve the GitHub reliability problem but it does mean I spend less time confused about what's happening in my repos.
GitHub's CTO has acknowledged the scaling challenges. The frequency of major outages has been increasing since December 2025. Until the platform stabilises, having better visibility into your own CI activity is the most practical thing you can do.

https://dailix.dev

The GitHub breach should make every developer rethink their notification blindspot

John Santias — Mon, 25 May 2026 06:42:03 +0000

I built Dailix because I completely stopped reading my GitHub notification emails. Too many, all looking the same, and the important stuff kept getting buried.

The breach that happened last week made me think about that habit differently.

If you haven't seen it: on May 19-20, GitHub confirmed that a threat actor compromised an employee's developer device via a malicious VS Code extension and used that foothold to clone roughly 3,800 of GitHub's internal repositories. GitHub says customer repositories and user data are not affected. The compromise is confined to their own corporate estate.

So your repos are fine. But the way it happened is worth paying attention to.

The trojanized VS Code extension was live on the Visual Studio Marketplace for only 18 minutes. That window was enough to distribute a credential stealer that harvested data from 1Password vaults, npm credentials, GitHub tokens, and AWS keys.

18 minutes. Most developers wouldn't notice something unusual in their GitHub activity in 18 days, let alone 18 minutes.

The blindspot problem

The breach happened silently. No alarm went off. No notification stood out. By the time anyone knew what had happened the credentials were already gone.

That's the same problem I was experiencing with CI failures on my own projects, not a security breach, just a build that had been failing for three days because it looked identical to the 40 other GitHub notifications I was ignoring.

The underlying issue is the same. When everything looks urgent, nothing does. And when nothing stands out, things slip through.

Developers who are drowning in GitHub notification noise aren't just missing failing builds. They're creating the kind of inattention that lets small things become big problems.

What this means practically

I'm not suggesting a daily email digest would have caught this breach. It wouldn't have. GitHub's internal systems are a different problem.

But it did make me think about what "paying attention to your repos" actually means in practice. Right now most developers have two modes: ignore everything, or check obsessively. Neither is useful.

The middle ground, a structured daily summary that surfaces anomalies, groups related failures, and tells you what actually changed, is what I've been building. Not because of security, just because of productivity. But the principle is the same.

If something unusual happens in your repos overnight, do you have a way to know about it when you open your laptop in the morning? Or would it look just like everything else?

If you want to try it: https://dailix.dev

I had hundreds of unread GitHub notifications. So I built this.

John Santias — Tue, 28 Apr 2026 10:51:05 +0000

I'm a backend and DevOps developer. I work across multiple projects at the same time.

At some point I realised I had completely stopped reading my GitHub notification emails. Not consciously, it just happened gradually. The volume crept up until my brain started filtering them out automatically, the same way you stop hearing an air conditioner after a while.

The problem is that some of those notifications actually matter. A failing build on main. A PR that's been waiting on my review for two days. A flaky test that's about to become a full failure. These things were sitting in my inbox and I was ignoring them because they looked identical to the 40 notifications around them that didn't matter at all.

The real cost of notification fatigue

It's not just the missed alerts. It's the cognitive overhead of deciding which ones to look at. Every time I opened GitHub notifications I had to context switch, scan the list, try to remember which repo was which, decide what was urgent, and usually give up halfway through and just mark everything as read.

I'd sometimes forget about a failing build on a side project for days. Not because I didn't care. Because I'd genuinely lost track of it.

What I wanted instead

I didn't want more notifications. I didn't want a dashboard to check. I wanted someone to look at everything that happened in my repos overnight and tell me: here's what's broken, here's what's waiting on you, here's what you should probably do first.

So I built it

Dailix connects to your GitHub account and sends one email every morning. Not a list of events, a digest. CI failures on the same repo get grouped together. Flaky tests get detected by watching for fail-then-pass patterns. PRs waiting on your review surface with how long they've been waiting. And an AI summary at the bottom reasons across all of it and gives you a ranked focus list.

The whole thing takes about 30 seconds to read. Then you know where things stand.

What the email looks like

Good morning. Here's your stack — Monday 21 April.

🚨 Needs your attention
payments-api main has been failing for 6h
3 builds down — test-suite and deploy-staging
Likely same root cause, last green was Sunday 9pm

👀 Waiting on you
auth-service — "Add OAuth token refresh" — 9h ago — 340 lines
user-service — "Fix pagination edge case" — 4h ago — 82 lines

✅ Shipped yesterday
8 PRs merged across payments-api, auth-service, user-service

💡 Focus suggestion
1. Fix payments-api main — been down 6h, 3 services depend on it
2. Review the auth-service PR — large change, been waiting 9h
3. Assign a reviewer to your notifications-api PR to unblock yourself

If this sounds familiar

I'm looking for developers to try it and tell me honestly if it's useful. It's free, takes 2 minutes to set up, and works on any GitHub repos.

https://dailix.dev