GitHub had a rough August. Five separate incidents degraded service across the platform, with Actions workflow runs failing to start, authentication latency spreading across services, and Copilot Cloud Agent tasks stuck showing stale status for hours. The company published a detailed incident report that’s worth reading if you care about how large-scale platforms break and recover.
But here’s what struck me: these weren’t exotic failures. They were the kinds of cascading problems that emerge when a system grows faster than its infrastructure can accommodate. And if you’re building on GitHub, especially relying on Actions for CI/CD, these incidents should prompt some hard questions about your own system design.
Growth Outpaces Infrastructure
GitHub’s core problem in August was straightforward: traffic and load grew faster than capacity. One incident stemmed from a routine Actions deployment that briefly reduced pod capacity in one datacenter, pushing remaining infrastructure past its limits. A second grew from database primary saturation as incoming events queued faster than the system could process them into runner assignments.
The common thread is that GitHub’s shared infrastructure services haven’t kept pace with month-over-month Actions growth. That’s not negligence. That’s the math of scaling a platform used by millions of developers. But it matters because Actions has become critical infrastructure for most projects on GitHub. When Actions falters, your CI/CD stops. Your deployments wait. Your releases slip.
What I found interesting was GitHub’s own transparency here. They didn’t hide behind vague statements. They traced specific failures: service-mesh sidecars hitting concurrency limits and not scaling up, load balancers exhausting network flow limits, latent retry bugs amplifying traffic to authentication endpoints. These are solvable problems, but they require architectural work that can’t be rushed.
The Azure Migration as Solution and Risk
GitHub is moving infrastructure to Azure. By August, they’d successfully migrated primary MySQL databases for the first time with minimal write impact. Git reads from Azure hit 54 percent. This is the long-term play to add capacity without the constraints of their current infrastructure.
But migrations at scale are risky. You’re running dual systems, learning failover patterns, increasing complexity as you migrate more critical workloads. August’s incidents happened during this transition. GitHub is explicitly trading short-term risk for long-term resilience, and I respect that honesty.
For developers, this matters because platform migrations affect reliability during the process. If you’re building systems that depend on GitHub Actions at high volume, you should expect occasional degradation over the next months as GitHub completes this work.
What Developers Should Learn About Resilience
The incident cascades in GitHub’s August report mirror patterns I see constantly: one failure doesn’t stay local. A deployment reduces capacity in one zone, pushing traffic to other zones that then exceed their limits. A database gets slow, queues back up, downstream services start retrying, retry storms amplify the load, and suddenly you have widespread authentication failures.
This is why isolation and graceful degradation matter. GitHub’s pull-request isolation work, where they moved unauthenticated traffic to separate infrastructure, is exactly the kind of hard work that prevents cascades. So is their push to reduce queries per second on shared databases by moving authentication services off overloaded primaries.
You can apply these patterns to your own systems. Isolate critical paths. Make components fail fast instead of backing up into retry storms. Monitor capacity headroom, not just utilization. When you’re at 80 percent utilization, you’re already too close to the edge under burst load.
GitHub also improved monitoring to measure merge, review, and comment failures independently instead of masking writing issues in high read volume. That’s instrumentation discipline. Most teams don’t instrument this granularly, then wonder why outages surprise them.
The Availability Principle
GitHub stated a clear principle after August: availability, then capacity, then features. That ordering matters. Availability first means you fix reliability problems before adding new functionality. Capacity second means you ensure you have headroom before you pursue features. Most teams do this backwards, chasing features while crossing their fingers about stability.
For anyone building with GitHub Actions, this principle should guide your own infrastructure work. If you’re running Actions at meaningful scale, your own capacity planning, monitoring, and isolation strategies need matching sophistication. GitHub handles billions of runs; you might handle thousands or tens of thousands, but the principles scale.
The deeper lesson is about DevSecOps practices and how incident response shapes architecture. GitHub’s team learned from August and made specific changes: capacity monitoring improvements, retry policy fixes, resiliency upgrades to core services. These aren’t new features. They’re infrastructure hardening informed by failure.
That’s the work that doesn’t make headlines but defines whether a platform stays standing when traffic spikes or components fail.