GitHub published its August availability report this week, and one sentence in it is worth more than the rest of the document: "our shared infrastructure services have not kept up with our month-over-month actions growth and peak load."
Five incidents in a month. The worst, on August 17, peaked at a 56% front-door request failure rate and touched more than 29,000 organizations, with roughly 4.8 million requests failing or crawling. On August 26, more than 20% of Actions run starts failed or were delayed, and that is the one GitHub attributes directly to growth outpacing shared services.
I want to be careful here, because it would be easy to read this as a GitHub problem. I do not think it is. I think it is the first large public example of a capacity model meeting a class of traffic it was never built to forecast.
Human traffic has a denominator
For most of my career, capacity planning had a number I could point at outside the system. Working on logistics APIs, the driver was parcels. Volume rose with commerce, peaked in a season everyone could name months in advance, and grew year over year in a band narrow enough to argue about. We disagreed about the multiplier. We did not disagree about the shape.
Internal systems worked the same way. Request volume tracked headcount, customer count, or transaction count. If you wanted to know what next year looked like, you asked someone in finance what they were forecasting and did arithmetic.
Agent traffic breaks that. The driver is not how many people you have. It is how many loops those people are running, and that number lives in a config file, a workflow matrix, or a retry policy. One engineer changing a concurrency setting on a Friday afternoon can move your load more than a quarter of hiring does. There is no external denominator to anchor the forecast to, which means the forecast is now a function of your own configuration surface.
Retries are the amplifier
The August 6 incident has a detail worth sitting with. A latent bug caused runners to retry revoked jobs instead of picking up valid work. That is a small bug. In a system already under pressure it is an accelerant, because retry traffic arrives exactly when there is no headroom left to serve it.
This is the failure shape I expect to see more of, not less. Agents retry. That is most of what makes them useful. The same property that lets an agent recover from a transient failure lets a fleet of them turn a brownout into an outage, and it does not require anybody to have written bad code. It requires a retry policy that was perfectly reasonable back when one caller had it.
I wrote a few days ago about idempotency being the guardrail that saves you at 2am. This is the other half of that argument, one layer down. Idempotency keeps a retry from duplicating an action. It does nothing about a retry storm consuming the capacity everything else needs.
The damage lands on the shared path
August 17 is the incident I would hand to a platform team. The proximate cause was a traffic surge past load balancer limits, but the reason it reached 29,000 organizations is that the degradation landed on a shared authentication path. Agent traffic did not take down the agent features. It took down issues, pull requests, the APIs, and webhooks.
That is the part worth checking in your own system this week. Not whether your agent workloads have capacity, but what they share with everything else. Connection pools, auth, DNS, a service mesh sidecar, one database primary. The blast radius of agent traffic is the set of things it shares, and most architecture diagrams do not draw that.
What I would actually do
Start with attribution, because you cannot forecast what you cannot count. If your logs cannot tell you what share of load came from an agent, which agent, and acting for whom, then your capacity model is guessing and so is your next postmortem. This is the same instrumentation argument I make about auditability, and it turns out to pay for itself twice.
Then give humans a lane. If agent workloads and interactive traffic share a pool, the agents will win, because they are patient and there are more of them. Separate queues, separate pools, or at minimum a priority that favours the request with a person waiting on the other end of it.
And treat concurrency settings as production configuration. If a change to a workflow matrix can double your peak, it deserves the same review as a schema migration.
One thing I got wrong
I have built capacity models off headcount growth that were confidently wrong, on a system where the real driver turned out to be a nightly batch job somebody had quietly parallelised. The model was fine. The denominator was wrong. I did not find that out during planning. I found it out during an incident, which is the expensive way to learn it.
The lesson I took from that is the one I would apply here. The question is not how much traffic you expect. It is what decides how much traffic you get, and whether that thing sits inside your system or outside it. For agent workloads it is inside. That is new, and it is worth re-planning around rather than scaling into.
Figures above are from GitHub's own availability report for August 2026.
