GitHub's 2026 Outage: AI Traffic Overwhelmed the Platform

On August 17, 2026, GitHub went dark for 7 hours and 47 minutes. This week they published the post-mortem, and it is unusually candid — three named failures, three concrete fixes, no hand-waving. Most providers issue a single summary paragraph and call it a day. GitHub drew you a map.

The map shows three compounding failures: an Istio service-mesh blind spot that disabled autoscaling, a VS Code retry bug that multiplied Copilot traffic much faster, and an AI agent-driven load surge that had quietly doubled GitHub's monthly traffic in four months. Each one alone would have been recoverable. Together they produced the longest GitHub-wide authentication outage in recent memory.

This post walks through what actually happened — the exact mechanism, not the press-release summary — and what you can take back to your own Kubernetes estate tonight.

The cascade, named and dated

GitHub published a clean timeline. By 14:24 UTC, enterprise teams using GitHub as their identity provider were locked out. SAML, OIDC, SCIM, and session-based logins all failed together. Peak error rates reached roughly 20% on web and API requests, and around 50% on archive and raw content downloads. GitHub Copilot stayed unreachable until 21:02 UTC.

The thing worth noting: the cascade was predictable. Each link in that chain has been a documented failure mode for years. The novelty is that all three hit on the same day.

The Istio autoscaling gap

This is the failure GitHub spent the most words on, and rightly so. GitHub runs Istio service-mesh sidecar proxies in front of inter-service communication. The horizontal pod autoscaler (HPA) was configured the way most HPAs are configured — by default.

# The default that broke GitHub on August 17
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: copilot-gateway
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: copilot-gateway
  minReplicas: 6
  maxReplicas: 60
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70
    - type: Resource
      resource:
        name: memory
        target:
          type: Utilization
          averageUtilization: 80

CPU and memory on the host application container. The Istio sidecar — sitting in the same pod, handling every outbound and inbound connection — was invisible to this policy. When the sidecar's concurrency limit saturated and started dropping connections, the application container was idle. Kubernetes saw green metrics. No scale-out triggered. The sidecar kept dropping traffic.

Four upstream HAProxy gateway nodes then absorbed the redirected load and exhausted their file-descriptor limits and connection-pool capacity. That collapsed the entire gateway authentication path.

Here is what a sidecar-aware policy looks like:

# Watch the sidecar, not just the host container
metrics:
  - type: Pods
    pods:
      metric:
        name: envoy_cluster_upstream_cx_active  # active upstream conns per sidecar
      target:
        type: AverageValue
        averageValue: "800"  # tune to your sidecar's tested concurrency ceiling
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

The Envoy stat envoy_cluster_upstream_cx_active reports active upstream connections per sidecar. When this approaches your tested concurrency ceiling, HPA scales the host deployment before users see a 503. GitHub's stated commitment: audit every HPA across its microservices footprint for the same blind spot.

If you run Istio, your audit starts tonight:

kubectl get hpa -A -o yaml | grep -A 20 'metrics:'

Look for any policy that references only cpu or memory. That is a 7-hour-47-minute incident waiting for a Tuesday afternoon.

The much faster Copilot amplifier

The second failure is uglier because it is software-level, not infrastructure-level. The VS Code extension for GitHub Copilot contained a retry bug. When the gateway returned non-2xx responses — which it started doing once the sidecar was saturated — the extension retried aggressively. Each retry opened a fresh long-lived streaming connection through the already-overwhelmed gateway. Copilot traffic multiplied by roughly much faster during the cascade window.

This is the retry-storm pattern, well-documented across a decade of incident reports. The lesson has not been learned at the client level:

• Retries need exponential backoff with full jitter, not fixed-interval retries.
• Retries need a circuit breaker — once you cross N consecutive failures, stop retrying for M minutes.
• Retries need a request budget — cap total in-flight requests per client session so one failing backend cannot consume every connection slot.

If you ship any client that talks to any backend over a long-lived connection, audit your retry policy this week. The bug GitHub found in VS Code is in your codebase too — it just hasn't been load-tested at production scale yet.

The AI traffic doubling nobody planned for

The third failure is the one the industry is least prepared to discuss. AI agents interacting with GitHub repositories — cloning, reading, indexing, syncing — had quietly doubled GitHub's total monthly traffic in four months. This was organic growth, not attack traffic. It was not malicious. It was simply unforecasted.

GitHub's infrastructure capacity planning assumed year-over-year growth at historical rates. AI agents grew traffic at multiples of that rate. By August, the baseline load on the gateway tier was roughly twice what it had been in April — and no one had rewritten the capacity model to account for it.

This is the new normal for every platform that hosts developer-facing APIs. Coding agents, research agents, indexing agents, eval harnesses — they all consume your endpoints at machine speed, on 24-hour schedules, with retry logic that assumes your service is healthy. The economic signal is positive (more usage is good). The planning signal is dangerous (more usage at unknown growth rates is an SLO risk).

Capacity planning that assumes organic human-driven traffic is now a legacy model. AI-driven traffic behaves like a CDN origin hitting your platform — steady, high-volume, and growing fast — and needs to be modelled as such.

The combined lesson: observability is not a feature

Three failures compounded because GitHub had good observability on the host container and zero observability on the sidecar, the client retry loop, and the AI-driven traffic curve. Each blind spot was small. Together they produced a near-total authentication outage.

What this gets you, if you run distributed systems at scale:

• Service-mesh-aware autoscaling. Sidecars and proxies are part of your request path. They need their own saturation metrics in HPA. Your Prometheus queries for any Istio deployment should include envoy_cluster_upstream_cx_active, envoy_listener_downstream_cx_overflow, and envoy_cluster_upstream_cx_overflow — these are the early-warning signals that fire before CPU moves.
• Retry-policy review for every client. Add a circuit breaker to anything that talks to anything else. Backoff with full jitter. A request budget. Three lines of code that prevent retry storms.
• Capacity planning that accounts for agent traffic. If your month-over-month traffic growth has accelerated in 2026, model the AI-driven component separately. If you can't measure it, instrument your most expensive endpoints and find out before August.

What doesn't change when the auth provider goes down

One underrated angle from this incident: when GitHub's SAML/OIDC authentication collapsed, every app that depended on GitHub as an identity provider locked out at the same time. CI runners failed. Internal developer portals failed. Mobile apps that used GitHub as their auth backend failed.

For teams that build product UIs on top of authentication infrastructure — web and native clients — the lesson is to architect for the inevitable. Auth providers fail. The patterns that survive that are the ones that keep a usable client when the network, or the identity backend, is unavailable: cached sessions, offline-tolerant read paths, graceful re-auth flows that do not block the whole UI.

When the authentication backend is unreachable, the same component should still render the shell of your app on web, iOS, and Android — one component definition, one API surface, behaviour that holds up when the network doesn't. That is the durable layer underneath the auth churn, and it does not change when your identity provider changes or has a 7-hour, 47-minute bad day.

The post-mortem as a pattern

GitHub did the right thing: published the actual mechanism, named all three causes, and committed to specific fixes. That is what a post-mortem is supposed to look like, and most providers do not ship them this way.

If you run distributed systems, copy the format. Three named failures. Three specific fixes. No "we are committed to reliability" boilerplate. Your future on-call team will thank you, and your peers will read it twice.