GitHub capacity outages 2025–2026 — what a year of failures teaches about load testing

GitHub is the version-control backbone for tens of millions of developers. When it goes down, pull requests stall, deployments stop, and CI pipelines fail globally. Between mid-2025 and early 2026, a cluster of outages made reliability headlines repeatedly — and the root story behind most of them was surprisingly simple: traffic grew faster than capacity.

This post walks through what happened, why the pattern repeats, and how to use load testing to catch the same failure class before it reaches production.

What happened

From October 2025 through April 2026, GitHub experienced a sustained cluster of availability incidents. The platform’s own CTO acknowledged the problem publicly, noting tight service coupling that allowed failures to cascade, an inability to shed load from high-volume clients, and services that required manual scaling instead of automating headroom. The company launched a 10×–30× capacity expansion program in response.

A particularly illustrative incident occurred on February 17, 2026, when GitHub’s authentication path degraded under peak read load. Database read replicas fell behind the primary under sustained traffic, causing inconsistent token lookups. Developers got intermittent failures even with valid credentials. The mitigation was to reroute reads and add additional replicas — actions that can only happen reactively once the problem is already visible to users.

The timeline

• October 2025 onward: Recurring outage cluster begins; agentic and AI coding workflows drive an accelerating traffic increase across repository, CI, and API paths.
• February 2, 2026: GitHub Actions degradation lasting approximately 3 hours and 40 minutes as job processing capacity saturates.
• February 17, 2026: Authentication path disruption; database read replicas lag under peak read load; token lookups return inconsistent results; engineering teams mitigate by rerouting reads and adding capacity.
• April 2026: Third-party analysis confirms capacity as the leading cause, attributing 83 of 257 incidents to it; GitHub’s CTO publicly addresses the coupling and load-shedding gaps.

Why it happened

Three reinforcing problems drove the cluster:

Traffic outpaced capacity. AI-assisted and agentic coding workflows dramatically increased API and repository traffic. Services that lacked automatic scaling required engineers to scale them manually after symptoms appeared — meaning capacity was always chasing the problem, not ahead of it.

Read replicas have a lag ceiling. Under sustained read-heavy load, database read replicas can fall behind the primary. At a certain throughput level, replication lag grows faster than it can be absorbed. The system crosses from “replicas occasionally a bit stale” to “reads returning wrong data” — and for authentication, wrong data means failed logins.

Tight coupling turned partial overload into cascades. When one service saturated, requests backed up into dependent services. Without load-shedding rules that could disconnect a single high-volume client or queue from the rest of the system, a localized overload spread into platform-wide degradation.

The failure pattern

This is a textbook capacity-ceiling failure: a system runs fine up to a throughput threshold, then degrades non-linearly as it crosses that threshold. The threshold is often invisible until it is crossed in production because teams test at today’s traffic, not tomorrow’s.

What makes this pattern dangerous is that it compounds. Replica lag feeds authentication failures. Authentication failures cause retries. Retries increase read load. The coupling GitHub’s CTO described is what turns a manageable overload into a widespread incident.

Any team whose read volume is growing — especially teams serving machine-generated or automated clients — is exposed to the same pattern.

How it could have been prevented

Autoscale critical paths. Manual scale-up is always late. Automated horizontal scaling, triggered on latency or queue depth, should run ahead of user impact.

Separate replica read limits from primary write capacity. Replica lag becomes dangerous when the replication topology has no headroom. Over-provision read replicas relative to current peak and set health alerts before lag reaches the danger zone.

Load-shed high-volume clients. High-volume automated clients (bots, agentic workflows) should be queued or rate-limited before they saturate shared infrastructure. This is rate limiting at the traffic-management layer, not just the application layer.

Find the breakpoint before users do. A breakpoint test run periodically tells you exactly where throughput plateaus and errors begin. Running it on a schedule ensures you learn about the drift before your users report it.

How to test for this with MaxoPerf

The recipe for catching a capacity ceiling has two parts: find the threshold, then monitor it over time.

Step 1 — Breakpoint test

Choose the paths most likely to saturate first: your authentication endpoint, your primary API read path, or whatever your traffic analysis says is growing fastest. Using k6 or Taurus with MaxoPerf, configure a breakpoint test that ramps concurrency in steps — for example, hold 50 virtual users for 2 minutes, then jump to 100, 200, 400, and so on. Run from at least two managed regions to represent realistic geographic distribution.

Watch three signals in the run results:

• Throughput plateau — where requests per second stops climbing even as VUs increase. That is your capacity ceiling.
• p95/p99 latency inflection — latency is flat during healthy operation, then bends sharply at saturation. Note the VU level where the bend starts.
• Error rate departure from zero — the first moment your error rate exceeds the baseline is the true ceiling your users will experience.

Step 2 — Scalability test

After you know your breakpoint, run a scalability test at 50%, 100%, 150%, and 200% of your current peak. This tells you whether your system scales linearly or whether it degrades non-linearly (the replica-lag pattern shows up here as latency climbing faster than VUs do).

Step 3 — Scheduled recurring runs

Traffic drift is silent. Schedule recurring breakpoint or scalability runs using MaxoPerf’s recurring test scheduler — weekly or after major releases. When your capacity floor starts dropping relative to your target, you know before your users do. Run results are stored with each execution, so you can compare the current run against last week’s baseline without any manual record-keeping.

For teams running private infrastructure (self-hosted runners, internal staging environments), MaxoPerf’s private/BYOC execution locations let you run the same test against your internal stack with the same results workflow.

Key takeaways

• Capacity-ceiling failures are usually invisible until crossed. Traffic growth is gradual; the threshold crossing is not. You need proactive measurement, not reactive scaling.
• Read replicas have a lag ceiling that is load-dependent. Any read-heavy path under sustained growth needs an explicit replica headroom target and an alert before lag becomes dangerous.
• Autoscale must be ahead of the symptom. Manual scale-up is always reactive. The automation must trigger on leading indicators (queue depth, latency trend) not lagging ones (error rate already rising).
• Tight coupling amplifies every overload. Load-shedding rules and circuit breakers convert a partial overload into a managed degradation instead of a cascade.
• A scheduled breakpoint run is the cheapest insurance. Running at multiples of current peak on a regular cadence catches drift before users report it.