skillindustry-newsAug 18, 2026 6 min read

GitHub Outage August 17: 20% API Errors, Actions and Copilot Hit

GitHub went degraded on 17 August 2026 around 13:40 UTC. Web and API traffic saw about 20% errors, raw and archive downloads about 50%. Pull requests, Actions, Copilot, and enterprise login all failed until GitHub marked the incident resolved at 21:15 UTC.

AI Research Team

Staff Writer

0 0

GitHub Outage August 17: 20% API Errors, Actions and Copilot Hit

GitHub, the Microsoft-owned developer platform, degraded worldwide on 17 August 2026 around 13:40 UTC (9:40 a.m. Eastern). Web and API traffic saw roughly 20% errors. Archive and raw repository downloads failed at about 50%. Pull requests, Issues, Actions, Webhooks, Pages, Copilot, and enterprise identity (SAML, OIDC, SCIM, Team Sync) all sat on the incident list. GitHub marked the incident resolved at 21:15 UTC and promised a root-cause analysis that had not landed by the morning of 18 August.

This is not a rumor thread. It is the status page, plus what broke for people who ship from GitHub every day.

What actually broke

The outage was partial, not a full blackout. Git operations, Packages, and Codespaces stayed up for long stretches. The parts that failed were the ones most teams treat as always-on: opening a pull request, hitting the API, kicking a workflow, downloading a zip of a repo, or asking Copilot to write the next function.

GitHub’s own numbers are the ones that matter. About one in five web and API calls errored. About one in two raw-file and archive downloads failed. That is enough to stall a merge queue and a release train without taking git clone fully offline.

Enterprise teams got a second punch. SAML and OIDC authentication, SCIM provisioning, and Team Sync sat on the same incident. If your org gates GitHub behind SSO, a “the website is slow” report was often an identity failure.

Timeline, in UTC

GitHub acknowledged the incident at 13:40 UTC on 17 August. Within about twenty minutes, API requests, Actions, Webhooks, Issues, and pull requests were listed as degraded. Around 16:36 UTC engineers said they had identified a problematic component and taken corrective action. At 16:59 UTC they called the main degradation mitigated and said they were watching for stability.

Recovery was not clean. Git operations, Issues, and the API each failed again within two hours of that mitigate note. Late updates mentioned sporadic authentication failures and a partial disable of authentication token retries. GitHub closed the incident at 21:15 UTC, thanking users and saying a detailed root-cause analysis would follow.

The Verge’s 17 August write-up matches the public clock: trouble from about 9:40 a.m. Eastern, resolve around 5 p.m. Eastern. Treat those as the U.S. window on the same UTC timeline, not a second incident.

Why this one stung more than a slow Actions queue

A queued workflow is annoying. A 50% failure rate on raw downloads plus a 20% API error rate is a different class of day. CI cannot fetch the repo. Review bots cannot comment. Deploy hooks never fire. Copilot, which many teams now treat as a default pair-programmer, sat degraded next to the classic collaboration tools.

If you run local coding agents as a backup, this is the week that choice paid for itself. Cloud IDEs and hosted models are fine until the host is the outage. The same lesson sits in fast agentic work on Gemini 3.6 Flash: keep a second path for the jobs that cannot wait.

August was already a noisy month

Monday was not GitHub’s first stumble this month. On 6 August, GitHub Actions degraded for roughly ten hours. GitHub later said a routine deployment exposed a capacity weakness, then a latent job-assignment bug kept runners retrying invalid work. At peak, about 71% of workflow runs hit infrastructure failures.

Trade press also noted a busy summer on the status page: eight degraded-service incidents in July, after nine in May and six in June. GitHub has said it is accelerating isolation work inside Actions and continuing an infrastructure migration toward Azure so one failure is easier to contain. Monday’s incident cut across APIs, auth, collaboration, automation, and Copilot at once, which is the opposite of a contained blast radius.

None of that proves a single root cause for 17 August. GitHub has not named one. Do not invent one.

What prompt and agent users should do next time

Treat GitHub as a dependency, not a given.

Keep a local clone of every repo you might need to ship from. Push mirrors to a second remote if the team can afford it. Cache Actions artifacts you cannot rebuild. If Copilot is in the critical path, keep a skill and a second model ready in tools so a degraded Copilot session does not freeze the desk.

Watch GitHub Status before you declare a self-inflicted CI bug. And read the news desk the next morning: a resolved incident is not the same as a published RCA.

FAQ

Is GitHub still down on 18 August 2026? No. GitHub marked the 17 August incident resolved at 21:15 UTC. The status page listed no new incidents on the morning of 18 August. A root-cause analysis had not been published yet.

When did the GitHub outage start and end? GitHub acknowledged it at 13:40 UTC on 17 August 2026 and resolved it at 21:15 UTC the same day. The worst error rates were posted around 14:04 UTC: about 20% on web and API traffic, about 50% on archive and raw downloads.

What services failed? Pull requests, Issues, Actions, API requests, Webhooks, Pages, Copilot, and enterprise identity (SAML, OIDC, SCIM, Team Sync). Git operations, Packages, and Codespaces were reported up for much of the window.

Did GitHub say what caused it? Not in public as of the morning of 18 August. Engineers said they identified a problematic component around 16:36 UTC. The resolve note promised a detailed RCA “as soon as it is available.”

Was this related to the 6 August Actions outage? GitHub has not linked them. The 6 August incident was a ~10-hour Actions degradation with a later RCA about a deployment and a job-assignment bug. Treat 17 August as a separate incident until GitHub says otherwise.