GitHub outage on August 17, 2026: seven hours of Unicorn errors and Copilot failures

GitHub was hit by a major global outage on August 17, 2026 that began with its infamous “Unicorn” error page and ended with a long tail of Copilot failures, lasting about seven and a half hours in total. StatusGator sent an Early Warning Signal at 13:35 UTC, five minutes before GitHub confirmed the incident on its status page at 13:40 UTC. User reports kept flowing until 20:12 UTC, well after the main site had recovered, because Copilot stayed broken for hours.

Incident at a glance

Was GitHub down on August 17, 2026?

Yes. GitHub suffered a broad, global outage on August 17, 2026 that lasted about seven and a half hours. The first wave was hard to miss: users worldwide hit GitHub’s “Unicorn” error page, the one that reads “No server is currently available to service your request.” Repositories would not load, commit history would not retrieve, and Pull Request and Issues pages failed. As one user in Bengaluru quoted from the error screen itself, “The Unicorns have taken over.”

Notably, GitHub’s own first status update, posted at 13:40 UTC, framed it far more mildly, describing an investigation into “impacted performance for some GitHub services.” For the thousands of developers staring at Unicorn pages across six continents, the impact was anything but minor.

What caused the GitHub outage?

GitHub’s root-cause analysis traces the outage to network saturation on load balancers in its Central US datacenter. A new peak in traffic overwhelmed those load balancers, and the failure cascaded from there. According to GitHub, the chain ran roughly like this:

• A service-mesh (Istio) sidecar pod hit its concurrency limit and failed to autoscale, because a scaling policy was misconfigured to watch the host service rather than the sidecar’s own limits.
• That failure cascaded until four HAProxy load-balancer nodes exhausted their connection limits, which degraded the gateway authentication path and produced the widespread sign-in latency and failures users saw.
• Aggressive retry logic made things worse, piling additional load onto internal load balancers. Engineers restored broad service by pausing HAProxy on the affected nodes simultaneously.

The long Copilot tail had its own twist. Some failing traffic was shifted to GitHub’s Northern Virginia region, where a latent retry bug in VS Code amplified requests by roughly 10 times. Client retry loops then drove Copilot Token Service traffic from a normal 7,000 to 9,000 requests per second up to 70,000 to 100,000, which is why Copilot kept failing for hours after the main site recovered. GitHub stabilized it by reducing gateway authentication retries and temporarily blocking the retry-triggering token requests, then ramping traffic back up gradually. Scraping attacks on codeload endpoints further complicated recovery.

GitHub’s follow-up actions include correcting the autoscaling policies to account for service-mesh sidecar capacity, auditing Istio concurrency and scaling limits, reviewing retry and backoff behavior across gateways and clients, fixing the VS Code retry behavior, and improving load-balancer capacity monitoring and regional failover safeguards.

How long was GitHub down?

The incident ran roughly seven and a half hours. The earliest report reached StatusGator at 12:47 UTC, volume surged from about 13:32 UTC, and the final reports tapered off around 20:12 UTC. GitHub opened the incident on its status page at 13:40 UTC and did not mark it fully resolved until 21:15 UTC. Recovery was uneven: the core site was mitigated in the late afternoon, but Copilot authentication failures lingered well into the evening UTC.

Timeline of the August 17 GitHub outage (UTC)

What and who was affected?

This was a genuinely global outage. Over the roughly seven-and-a-half-hour window, StatusGator logged more than 440 user reports, pouring in from across India, the UK, Germany, the US, Canada, Brazil, and dozens of other countries, from Bengaluru and Chennai to London, Berlin, São Paulo, and Toronto. Because the failure hit shared infrastructure, it touched nearly every part of the platform.

In the first phase, users could not:

• Load repositories or view files, branches, and commit history (“Cannot retrieve latest commit at this time”)
• Open Pull Requests or Issues pages
• Sign in, with many seeing the Unicorn “No server is currently available” screen
• Run Actions or download archives and raw content reliably

In the second phase, the pain concentrated on Copilot. Developers reported completions and chat failing with “Language model unavailable” across VS Code, Visual Studio, and JetBrains IDEs. The frustration was palpable and sometimes funny: one developer in Germany wrote that with Copilot down, “Now I have to think again by myself.” Another in Miami declared simply, “It’s dead Jim!”

Crucially, several users flagged the gap between the official all-clear and reality. One in California noted that Copilot was “still not responding, although MS reports GitHub is now fixed,” and a user in Cambridge summed up the whole arc: GitHub came back after about 20 minutes, but Copilot still reported models unavailable.

How did StatusGator detect the outage early, and track it accurately?

StatusGator sent its Early Warning Signal at 13:35 UTC, five minutes before GitHub’s status page opened the incident at 13:40 UTC. GitHub acknowledged this one quickly, so the initial lead was short, but the real value showed up over the length of the incident.

The user report feed tracked the true user experience, not just the official component states. While GitHub began marking services as operating normally in the late afternoon, StatusGator kept receiving Copilot failure reports for hours, right up to 20:12 UTC. For a team relying on Copilot, the outage was not over when the website came back, and the crowd-sourced signal reflected that reality.

There is also the matter of noise. GitHub posted more than 30 separate status updates across eight components during the incident, with services flapping between degraded, mitigated, and normal. On the other side, more than 440 user reports flooded in from around the world. StatusGator condensed both into a clear signal and consistent notifications, so subscribers did not have to parse a component-by-component stream to understand whether they were affected.

For historical context, you can review GitHub’s outage history and the GitHub outage map to see how often these events happen and where they land.

Lessons for teams that depend on GitHub

• Do not trust a partial all-clear. Sub-components were marked normal well before Copilot users were actually working again. Watch real user signals, not just the status page.
• Treat intermittent errors as an incident. A 20 percent failure rate and random Unicorn pages quietly break pushes, merges, and CI even when the site is not fully down.
• Plan for authentication and AI tails. Sign-in and Copilot auth were the slowest to recover. If your workflow depends on them, have a fallback and a comms plan.
• Aggregate your signals. During a multi-hour, multi-component incident, one consolidated source beats refreshing a dozen component pages.
• Turn on proactive alerting. Early Warning Signals exist for the window when reports are climbing but the provider has not posted yet.

Frequently asked questions

Monitor GitHub with StatusGator

If your team builds on GitHub, a seven-hour outage can stall pushes, pipelines, deploys, and AI assistance across the whole company. StatusGator combines official status pages with real user reports and sends Early Warning Signals the moment a pattern emerges, then keeps you informed through every twist of a long incident, including the tail that the status page can miss.

Start monitoring with StatusGator and get early warnings for the services your team depends on.