GitHub Is Down: The August 17, 2026 Outage in Detail

On August 17, 2026, GitHub broke for developers around the world. The company confirmed the outage at 13:40 UTC (Coordinated Universal Time, the time standard used by most of the internet). Error rates quickly climbed to about 20% for the website and the API (Application Programming Interface, the interface programs use to talk to GitHub). Downloads of repository archives and raw files failed at roughly double that rate.

The outage hit the parts of GitHub that developers depend on every day: the website, the API, Actions, Webhooks, Issues, Pull Requests, and Copilot. As of this writing, GitHub has not announced a root cause. The official status page still says investigations are ongoing.

Here is what we know, what I could verify myself, and what it means for anyone who builds software.

The timeline so far

All times are in UTC on August 17, 2026. They come from GitHub's own status page and from BleepingComputer's coverage:

13:40 - GitHub says it is investigating reports of impacted performance for some services.
13:41 - API Requests show degraded performance.
13:42 - Actions shows degraded performance.
13:44 - Webhooks shows degraded performance.
13:45 - GitHub reports an approximate 20% error rate across numerous experiences, including Pull Requests and Issues.
13:46 - Issues shows degraded performance.
13:58 - Pull Requests shows degraded performance.
14:04 - The error rate is around 20% for web experiences and API traffic. Archive downloads and raw repository content downloads are seeing an approximate 50% error rate.
14:24 - SAML and OIDC authentication, SCIM, and Team Sync are also impacted.
14:31 - Copilot is experiencing degraded availability.
14:45 to 14:54 - Pull Requests and Issues remain degraded. The status page still says investigations are ongoing.

DownDetector, an outage tracking service, recorded a surge in user reports around 9:25 AM Eastern Time, which is 13:25 UTC. BleepingComputer confirmed the outage and described it as worldwide in coverage published at 10:47 AM Eastern Time. The gap between the first user reports and GitHub's own confirmation was only about 15 minutes.

What a 20% error rate looks like in practice

Percentages sound abstract. Here is what they mean when you are actually working:

One in five page loads on github.com fails. The browser shows an error page instead of your repository.
One in five API calls fails. CI/CD pipelines (continuous integration and continuous delivery, the automated systems that build and deploy software) return 5xx errors, the HTTP (Hypertext Transfer Protocol, the foundation of web communication) status codes that mean "the server failed".
One in two archive downloads fails. Downloading a repository as a ZIP file, or fetching a single raw file, fails about half the time.
Enterprise users may not be able to log in at all. SAML (Security Assertion Markup Language) and OIDC (OpenID Connect) are how many companies authenticate their employees. SCIM (System for Cross-domain Identity Management) is how they sync user accounts automatically. All three were impacted.
Copilot, the AI assistant inside code editors, becomes slow or unavailable. Millions of editors feel it at the same time.

In short, the slow parts were the "thinking" parts of GitHub: the web layer, the API layer, and the file-serving layer. That distinction matters, because the core git operations appeared to be a different story.

What I could verify myself

I ran my own checks from a server outside GitHub's network while the outage was active. This is a small sample, one location at one moment, but it lines up with GitHub's own status updates:

The github.com website responded in 0.07 seconds with HTTP 200, the success code. The page itself loads fine.
A normal git operation over HTTPS (the secure version of HTTP) worked. I was able to list the remote branches of a public repository without errors. This is the same protocol used for clone, fetch, and push.
The API responded, but very slowly. One request took 10.8 seconds. A healthy API answers in well under a second.
A raw file download came back with HTTP 429, the "too many requests" code. The service was rate limiting instead of serving files.
A repository archive download timed out after 25 seconds. The request never completed.

Interpreted together: the git protocol that clones and pushes code kept working during my tests. The broken parts were the web experience, the API, and raw and archive file serving. That matches GitHub's status page, which reported high error rates for "web experiences and api traffic" and separate problems with archive and raw downloads.

One caveat: error rates fluctuate during an incident. GitHub reported about 20% of API requests failing, so some users will have worse experiences than I did, especially if their traffic is routed to a different region. My test is a single data point, not a guarantee.

Why this matters more than a normal outage

GitHub is not a small platform. Its Octoverse 2025 report, published by GitHub itself, says more than 180 million developers build on the platform. The report says 36 million new developers joined in 2025, which works out to more than one new developer every second.

The same report says 80% of new developers start using GitHub Copilot within their first week. Copilot lives inside the editor, which means a Copilot problem is felt in millions of open editors at the same time, even by people who are not touching GitHub directly.

The larger change is what GitHub has become over twenty years. In 2006 it was a place to store and share code. Today it is also the CI/CD engine for a large share of the industry, the host of automated build pipelines, the reviewer of pull requests, an identity provider for enterprises, and an AI assistant vendor. A partial outage like this one is not limited to the website. It stalls automated deployments, delays code reviews, blocks enterprise logins, and pauses AI-assisted coding sessions. One company, one DNS (Domain Name System, the phonebook that turns names into addresses) entry, and a huge share of the industry slows down together.

A rough month for GitHub

This is the fifth notable incident in the past three weeks, according to GitHub's incident history:

July 29 - Actions experienced elevated API timeouts, failing runner registration, and delayed workflow starts. The cause was an under-provisioned internal service. About 2% of workflows were delayed.
July 30 - The Claude Fable 5 model in Copilot degraded for 73 minutes because of an upstream model provider issue.
August 10 - Users could not create new fine-grained personal access tokens through the website.
August 13 - Enterprise Team Sync was disrupted, and Copilot's Fable 5 model produced elevated errors again.
August 17 - Today's partial outage, which was still ongoing as of writing.

None of these is catastrophic on its own. Seen together, they show how much surface area GitHub now operates: git hosting, CI/CD, identity, code review, AI models, and more. Every one of those surfaces is a place where something can break, and the company is shipping new AI features faster than ever before.

What developers can do right now

The practical list is short:

Check the official status page first. It is updated frequently during incidents, and it names the affected services. Before you debug your own network, confirm the problem is on GitHub's side.
Keep using git over HTTPS or SSH. Core git operations appeared to work in my tests. Clone, fetch, and push may succeed even when the website is slow.
Retry failed downloads later. Archive and raw file downloads were failing about half the time at the peak. A retry after the incident recovers will likely work.
Re-run failed CI/CD jobs after recovery. A pipeline failure during the incident is not a verdict on your code. Most runners let you re-run a failed job with one click.
Enterprise users stuck at login should wait. Authentication services were impacted. The accounts themselves were not reported as compromised, and the status page did not mention data loss.

Longer term, this is a reminder of resilience habits that were already worth having. Cache your dependencies. Keep a mirror or a backup route for critical downloads. Do not design a workflow where one failed API call blocks the entire release. And if your company depends on GitHub for releases, have a written plan for the hours when the platform is slow. The plan can be simple: who checks the status page, who decides to pause a release, and how users are told what is happening.

The question nobody can answer yet

The root cause is still unknown. GitHub has not published one as of this writing. Some community threads are already speculating that AI-driven growth is straining GitHub's architecture. One ResetEra thread from today is titled "GitHub's down, again. Yes it's probably AI's fault".

That theory is plausible. The Octoverse numbers show explosive growth during the AI era, and Copilot traffic is a genuinely new and heavy load on GitHub's infrastructure. But plausible is not the same as confirmed. Until GitHub publishes its post-incident analysis, the honest answer is that we do not know.

What we do know is concrete. The outage started around 13:25 UTC, peaked with about 20% error rates on web and API traffic and 50% on raw and archive downloads, and was still being investigated at 14:54 UTC. Core git operations kept working during my tests. GitHub's incident page on the status site is a reliable place to watch for updates, and the company will almost certainly publish a post-incident analysis once the investigation concludes.