GitHub confirms 7 hours and 47 minutes of downtime on August 17

⏱️ Lectura: 11 min

GitHub was down for seven hours and forty-seven minutes on August 17, 2026: the longest outage the company has acknowledged so far this year. The GitHub outage took down github.com, authentication, GitHub Actions, the APIs, pull requests, issues, and Copilot all at once, leaving thousands of teams unable to deploy software for an entire workday.

📑 En este artículo

1. TL;DR
2. What happened in the August 17 GitHub outage
3. Context and history: the second serious incident of August
4. Technical details and performance: how much infrastructure GitHub added
5. How to protect your own backend against a retry storm
6. Impact and analysis
7. What’s next
8. Frequently Asked Questions
   1. How long did the August 17 GitHub outage last?
   2. Which GitHub services were affected?
   3. Was it an attack or a code bug?
   4. Why did Copilot take longer to recover than the other services?
   5. What percentage of GitHub’s infrastructure runs on Azure today?
   6. What is a retry budget and how does it differ from a fixed retry limit?
9. References

The company published the post mortem on August 20, 2026, signed by CTO Vlad Fedorov, and admits that neither of the two August incidents (the one on the 6th and the one on the 17th) was caused by a code or configuration change: both were capacity failures.

TL;DR

• On August 17, 2026, GitHub suffered a 7-hour-47-minute outage that affected github.com, authentication, Actions, APIs, pull requests, issues, and Copilot.
• It was the second serious incident of the month, following the Actions failure on August 6, 2026.
• The cause: a critical infrastructure component in the Central US datacenter didn’t scale in the face of a record traffic spike.
• Neither this incident nor the one on August 6 was caused by a code or configuration change: both were capacity failures.
• Copilot took longer to recover because a client-side retry loop amplified traffic during recovery.
• Since April 2026, monthly commits on GitHub rose from 1.4 billion to 2.9 billion.
• GitHub added more than 3 million CPU cores and 120 petabytes of high-speed storage since March.
• Azure now handles close to 58% of the platform’s load and half of all Git operations, up from 12% in May 2026.

What happened in the August 17 GitHub outage

The root of the problem was simple to describe and hard to prevent: traffic hit a new peak, and a critical infrastructure component in the Central US datacenter didn’t scale in time. GitHub explains in its official incident report that the resulting capacity pressure spread through its systems, triggering authentication failures that dragged down github.com, Actions, the APIs, pull requests, and issues.

Recovery required several coordinated actions in parallel: teams redirected traffic, isolated the affected infrastructure, and restored services in stages. Most GitHub services came back early that same day, but Copilot took much longer.

The reason for Copilot’s delay was a classic effect of any distributed system under stress: errors in those services triggered a client-side retry loop that, instead of relieving the load, increased it right when GitHub was trying to recover. The company had to mitigate that behavior before it could safely restore traffic. This is what reliability engineering calls a retry storm: every client that retries after a 5xx error adds more load to a system that’s already down, and the system takes longer to recover the more the client insists.

💭 Key point: a retry storm isn’t a bug in a single service: it’s an emergent property of thousands of clients reacting the same way to the same error, at the same time.

sequenceDiagram
    participant U as Copilot Client
    participant GW as GitHub Gateway
    participant BE as Copilot Backend
    U->>GW: requests completion
    GW->>BE: forwards the request
    BE-->>GW: responds with error 503
    GW-->>U: responds with error 503
    Note over U: the client retries without waiting
    U->>GW: immediate retry
    U->>GW: immediate retry
    Note over GW,BE: retry traffic exceeds the original

Context and history: the second serious incident of August

This wasn’t an isolated failure. August 17 was GitHub’s second serious incident in less than two weeks, following an Actions failure on August 6, 2026. Fedorov had already shared, back in March and April 2026, the ongoing work to improve platform reliability, so the company entered August with an active availability roadmap, not reacting from scratch.

Growth explains much of the pressure: since April 2026, monthly commits on GitHub rose from 1.4 billion to 2.9 billion, more than doubling in just a few months. GitHub acknowledges this without using it as an excuse: that growth explains the pressure on its systems, but the company itself admits it doesn’t justify the outages, according to the official blog.

Technical details and performance: how much infrastructure GitHub added

As part of this year’s reliability commitments, GitHub prioritized three fronts: adding capacity, improving efficiency, and eliminating architectural bottlenecks. Since March, the company has added more than 3 million CPU cores, 120 petabytes of high-speed storage, and additional network capacity, installing all the hardware that the available power in its datacenters allowed, while accelerating its migration to Azure.

That migration is already significant: today Azure serves around 58% of GitHub’s platform load and half of all Git operations, up from just 12% of the platform load in May 2026. That jump in just a few months also accelerated the work to scale the platform’s largest monorepos.

The next technical milestone is an architecture that scales read capacity linearly with the number of readers, which in practice enables read operations with no artificial upper limit. GitHub will roll it out gradually, starting with the largest monorepos, where the concurrent-reads problem is most acute.

How to protect your own backend against a retry storm

The pattern that amplified the GitHub outage in Copilot (uncontrolled retries during a recovery) is the same one that can take down any backend of your own during a traffic spike. The standard solution in reliability engineering combines three pieces: retry limits, retry budgets, and variable timeouts with jitter. This is exactly what GitHub announced it will apply consistently across all its service-to-service interactions.

Strategy	When to use it	Advantage	Limitation
Fixed retry with exponential backoff	Isolated, one-off failures from a client	Simple to implement	Doesn’t stop a storm if thousands of clients retry at once
Retry budget	Services with many concurrent clients	Limits the percentage of traffic that can be a retry, not the absolute amount	Requires real-time traffic metrics per service
Circuit breaker	Dependencies that fail persistently	Cuts calls to a downed service and prevents further saturation	If poorly calibrated, it can open the circuit on normal transient failures
Variable timeout with jitter	Systems with many synchronized clients	Prevents all clients from retrying at the same instant	Increases perceived latency in the worst case

A naive client, with no controls at all, looks like this:

async function fetchCompletion(prompt) {
  for (let intento = 0; intento < 5; intento++) {
    const res = await fetch("https://api.copilot.example.com/v1/complete", {
      method: "POST",
      body: JSON.stringify({ prompt })
    });
    if (res.ok) return res.json();
  }
  throw new Error("all 5 attempts failed");
}

This client retries immediately with no backoff or budget: if the service is already overloaded, every retry adds more load at the worst possible moment.

The version with a retry budget limits how much extra traffic the resilience mechanism itself can generate:

class RetryBudget {
  constructor(ratioMaximo = 0.1, ventanaMs = 10000) {
    this.ratioMaximo = ratioMaximo;
    this.ventanaMs = ventanaMs;
    this.solicitudes = [];
    this.reintentos = [];
  }

  registrarSolicitud() {
    const ahora = Date.now();
    this.solicitudes.push(ahora);
    this._limpiar(ahora);
  }

  puedeReintentar() {
    const ahora = Date.now();
    this._limpiar(ahora);
    const permitido = this.solicitudes.length * this.ratioMaximo;
    return this.reintentos.length < permitido;
  }

  registrarReintento() {
    this.reintentos.push(Date.now());
  }

  _limpiar(ahora) {
    const limite = ahora - this.ventanaMs;
    this.solicitudes = this.solicitudes.filter(t => t > limite);
    this.reintentos = this.reintentos.filter(t => t > limite);
  }
}

const budget = new RetryBudget(0.1, 10000);

async function fetchCompletionConPresupuesto(prompt) {
  budget.registrarSolicitud();
  const res = await fetch("https://api.copilot.example.com/v1/complete", {
    method: "POST",
    body: JSON.stringify({ prompt })
  });
  if (res.ok) return res.json();
  if (!budget.puedeReintentar()) {
    throw new Error("retry budget exhausted, not retrying");
  }
  budget.registrarReintento();
  await new Promise(r => setTimeout(r, 200 + Math.random() * 300));
  return fetchCompletionConPresupuesto(prompt);
}

With a 10% retry budget, the service can never receive more than 10% additional traffic from retries on top of the original traffic, no matter how many clients are failing at once. That’s exactly what was missing from Copilot’s path during the August 17 GitHub outage: nothing limited how much retry traffic could grow during recovery.

To confirm that a retry budget is active in production, the minimum is to expose a retry-rate-over-total-traffic metric (retry_ratio) and alert if it exceeds the configured threshold, instead of trusting that the code will never exceed the limits you defined.

⚠️ Watch out: a fixed per-client retry limit doesn’t prevent a retry storm if you have thousands of clients retrying simultaneously: the limit has to be on the service’s aggregate traffic, not per individual client.

Impact and analysis

The real cost of the GitHub outage isn’t the 7 hours and 47 minutes themselves, but what they represent for an ecosystem that depends on a single centralized platform for authentication, CI/CD, and version control. When GitHub Actions goes down, it’s not just deployments that stop: tests, automated reviews, and any pipeline that depends on a runner stop too. For teams without a contingency plan, the GitHub outage translates directly into lost work hours.

The most relevant data point in the report isn’t the incident itself, but what it reveals about GitHub’s internal architecture: a platform that ran just 12% of its load on Azure in May 2026 now runs 58%, in the middle of an active migration. Moving half of all Git operations from one infrastructure to another while traffic doubles is, in itself, an additional risk factor, even though GitHub doesn’t mention it as a direct cause of the incident.

What’s next

GitHub identified two immediate changes stemming from the August 6 and 17 incidents. The first is applying consistent retry limits, retry budgets, and variable timeouts across all service-to-service interactions, to prevent retry storms and cascading load like the one that delayed Copilot’s recovery. The second is reviewing low-priority CPU and memory alerts to identify components that could fail under sudden traffic spikes, before they fail in production.

At the architecture level, the underlying work remains the same as what Fedorov described in March and April: isolating critical systems and eliminating shared dependencies between them, so that a capacity failure in one component doesn’t spread to the rest of the platform as happened on August 17.

📖 Summary on Telegram: View summary

Try it yourself: check whether your backend currently exposes a retry_ratio metric, and if it doesn’t, that’s a good starting point before your next traffic spike.

Frequently Asked Questions

How long did the August 17 GitHub outage last?

Seven hours and 47 minutes, from the start of the incident to the full recovery of all services, including Copilot.

Which GitHub services were affected?

github.com, authentication, GitHub Actions, the APIs, pull requests, issues, and Copilot.

Was it an attack or a code bug?

No. GitHub confirmed that neither this incident nor the one on August 6, 2026 was caused by a code or configuration change: both were capacity failures in the face of a traffic spike.

Why did Copilot take longer to recover than the other services?

Because errors in Copilot triggered a client-side retry loop that increased traffic during recovery, an effect known as a retry storm.

What percentage of GitHub’s infrastructure runs on Azure today?

Around 58% of the platform’s load and half of all Git operations, up from 12% of the platform load in May 2026.

What is a retry budget and how does it differ from a fixed retry limit?

A retry budget limits the percentage of total traffic that can be retries, not the number of retries per client; this prevents thousands of clients retrying at the same time from saturating a service that’s already degraded.

References

• The August 17 outage, and the work ahead: GitHub’s official post mortem signed by CTO Vlad Fedorov, the primary source for all incident data.
• GitHub Status: GitHub’s official status page, where it reports incidents and recovery times in real time.
• Handling Overload, Google SRE Book: reference chapter on retry budgets and handling overload in distributed systems.
• Microsoft Azure Documentation: official documentation for the infrastructure GitHub is migrating workloads to.

📱 Enjoying this content? Follow @programacion on Telegram for daily tech content in Spanish: quick summaries, fresh content every day.

Imagen destacada: Foto de Elimende Inagella en Unsplash