If an external development firm handling your project notifies you that "progress is blocked today because GitHub is down," how would you take it? Whether it sounds like an excuse or a reasonable report depends on whether you understand what stops and to what extent.
On August 17, 2026, GitHub suffered an outage lasting 7 hours and 47 minutes. It affected not only github.com itself, but also authentication, Actions, APIs, pull requests, Issues, and even Copilot. The retrospective published on August 20 contained insights valuable even for client organizations commissioning development.
The cause was not code, but capacity
The incident began when critical infrastructure components in the Central US data center failed to scale in tandem as traffic reached an all-time high. GitHub explained that the outage was not directly triggered by code or configuration changes, but was fundamentally caused by a lack of storage capacity.
Behind this was a surge in usage volume. Monthly commits doubled in about four months, jumping from 1.4 billion in April 2026 to 2.9 billion. As a result of development by AI agents becoming widespread, repository write operations doubled without any increase in the human headcount. The assumptions underlying capacity planning had departed from historical growth trajectories.
This is not someone else's problem. If capacity planning for your internal systems is estimated using "number of users × average number of operations," it will miss the mark in the exact same manner. When assuming operations by agents, the distribution of operations per user shifts.
What prolonged it was retries
The most practical takeaway when reading the report was the reason recovery was delayed.
A massive volume of retries generated during the outage drove up load on internal load balancers, exacerbating the situation. Specifically, in the service handling Copilot authentication tokens, requests that normally run at 7,000 to 9,000 requests per second swelled to between 70,000 and 100,000 requests per second. It was noted that aggressive retry behavior upon authentication failure on the client side (Visual Studio Code) likely contributed.
Consequently, Copilot's recovery lagged behind other services. As preventive measures, GitHub stated that it will apply consistent retry limits, retry budgets, and adaptive timeouts across inter-service calls.
This pattern occurs regardless of scale. If your company's mobile app or business system is built to retry immediately upon receiving an error from the server, traffic will multiply several to tenfold the moment an outage occurs. Even if you bring servers back up to recover, waiting clients rush in simultaneously and knock them down again. This is the type of problem that is hard to notice during development and surfaces for the first time during a production incident.
If specifying this as a requirement when commissioning development, a single sentence suffices: "Client retries upon error must have a maximum count, exponential backoff, and jitter." Implementation cost is virtually negligible.
Three areas where it pays for the ordering party to prepare
It makes little sense to say, "If GitHub can go down, let's host elsewhere as well." The cost of duplication is disproportionate. If you are to prepare, focus on the following three areas.
1. Decide how deadlines are handled beforehand. Check whether your contract specifies how delivery deadlines are treated if work halts due to an external service outage. If it is not documented, it becomes an emotional dispute when it happens. A single sentence resolves it.
2. Coordination for release day. When an outage hits, what causes real distress is release operations rather than routine development. If CI is unavailable, you cannot deploy. It is worth verifying whether there is a manual rollback path available on critical release days. We outlined how to design business continuity during SaaS outages in Principles of Business Continuity Assuming SaaS Outages.
3. Location of the code. For a client commissioning development, this is the most critical point. Beyond the outage itself, is the codebase you paid to have built under your company's control? Having it reside solely under the development contractor's account causes friction upon contract termination even more than during outages. How to ensure this in contracts is addressed in Is Code Repository Location Stated in Your Contract?
Choosing how things fail rather than multiplying what never fails
Every time an outage like this occurs, debates arise over whether everything should be self-hosted; however, expecting a self-hosted setup to recover faster than 7 hours and 47 minutes is virtually impossible. Few organizations can maintain an operational structure more robust than GitHub's.
What is realistic is to understand what halts when an outage occurs, and establish alternative paths only for items whose disruption cannot be tolerated. Prioritizing development downtime as acceptable while considering an inability to deploy production environments unacceptable is standard. We discussed evaluating whether added components can later be decoupled in Can You Decouple the Components You Introduce? The same question applies to external services you rely on.
What to do next
First, check how many times and at what intervals clients retry upon encountering an error in your systems. If not explicitly configured, library default values are in effect. There is no guarantee that default values are appropriate for your system's load tolerances.
Furthermore, add a single line in your next contract renewal defining how delivery deadlines and work are handled during external service outages. It is far cheaper than trying to decide after an incident occurs.
GleamHub offers consultations regarding custom development, AI, and automation to assist with mapping system dependencies, reviewing architectures designed for failure, and defining retry and timeout policies. Because remediation priorities differ depending on your existing architecture, please consult with us individually. Reach out via Contact Us.
