Around 9:40 AM ET on August 17, 2026, GitHub posted a one-line update: it was investigating reports of impacted performance.
Six minutes later, Pull Requests were degraded, then Actions, Webhooks, and Issues. Within half an hour, GitHub confirmed roughly 20% error rates across web and API traffic, with archive downloads and raw repository content failing at closer to 50%. Thousands of developers reported problems on Downdetector over the course of the morning. By early afternoon, GitHub said it had identified the problematic component and was seeing strong signs of recovery—though it was still working to fully restore service as of that update.
Here's the question to consider while the outage is still fresh: what would this have cost your team if it had lasted a day instead of a few hours? Could your developers keep working?
This Isn't a One-Off
It's tempting to treat this outage as a fluke. It isn't.
On August 6, GitHub Actions went down for 10 hours and 42 minutes, with 71% of workflow runs failing outright at peak and roughly 85% of webhooks going undelivered. That means some pushes and pull requests never triggered CI at all, and can't be replayed automatically.
In March, GitHub's CTO Vlad Fedorov published a direct acknowledgment of "significant availability and performance issues," walking through three major incidents in February and March, admitting the company hadn't met its own reliability standards. A month later, he wrote again to explain that a plan to scale GitHub's capacity 10x had turned into a plan to scale it 30x, driven by explosive growth in AI-driven development workflows.
None of this is a knock on GitHub's engineering team. They've been fully transparent about these outages. But this platform that many organizations depend upon is under real, ongoing strain. This is part of a growing trend: more critical IP is concentrating behind fewer platforms, just as those platforms are visibly straining to keep up.
If outages like this are a part of operating at scale, your team needs a plan for when they occur.
What It Looks Like to Actually Have an Answer
Fortunately, Rubrik is built for exactly this problem. Consider these three key pieces of our DevOps resilience platform:
Cross-platform recovery: When GitHub is down, Rubrik can restore your repositories to a different tenant, a different org, or a different environment entirely, including directly into Azure DevOps. Instead of waiting for the outage the end, your team regains access to their code and keeps building somewhere else while GitHub recovers.
Recovery from GitHub SaaS to GitHub on-prem: If github.com itself is unavailable, Rubrik can now recover your repositories and workflows into a self-hosted GitHub Enterprise Server environment. Now you can keep running your existing processes on infrastructure you control, independent of whatever is happening on GitHub's side. This capability is currently in beta.
Air-gapped, immutable recovery: Rubrik backups sit entirely outside your GitHub environment, in a logically air-gapped, immutable format. That way, a compromised token, a rogue automation or AI agent, or a force-push in your live repos can't reach them. If an outage is ever followed by (or used to mask) actual deletion, you still have a trusted, verified point to restore from.
How Rubrik Can Help
Nobody, including GitHub, could have stopped these outages from happening. So let's not let a good opportunity go to waste: an outage like this can reveal if your team can keep working if they lose access to your source code. Better to learn now then to wait until you're forced to find out the expensive way.
If you don't have that answer yet, take a look at what Rubrik DevOps Protection for GitHub can do. It's a lot easier to set up on a quiet Tuesday than during the next incident.
Any unreleased services or features referenced in this document are not currently available and may not be made generally available on time or at all, as may be determined in our sole discretion. Any such referenced services or features do not represent promises to deliver, commitments, or obligations of Rubrik, Inc. and may not be incorporated into any contract. Customers should make their purchase decisions based upon services and features that are currently generally available.