GitHub's 8-hour outage started with an AI coding tool. That's the same infrastructure your internal automation runs on

A retry bug in an AI coding assistant helped take down GitHub's pull requests, Actions, and API access for nearly 8 hours on August 17, 2026. If your firm has started building its own submittal, RFI, or estimating automation on GitHub's infrastructure — a growing pattern as contractors weigh buying AI tools versus building them in-house — that outage was your outage too, whether or not anyone at your company opened GitHub that day.

What actually broke

GitHub published its incident report on August 19. The chain of failure: an Istio sidecar, a piece of networking infrastructure that manages traffic in GitHub's Central US data center, hit its concurrency limit. GitHub's autoscaling policy was supposed to catch that and add capacity, but it was configured to monitor the host service rather than the sidecar itself, so it never triggered. Separately, a latent bug in VS Code's retry logic kept resubmitting failed requests to GitHub's Copilot Token Service, pushing that service's traffic from a normal 7,000-9,000 requests per second up to as much as 100,000 — roughly a 10x spike that piled onto an already-overloaded system.

The outage ran from 13:28 to 21:15 UTC — about 7 hours 47 minutes. GitHub mitigated it by cutting gateway retry rates and temporarily rejecting Copilot Token Service requests outright with an HTTP 403 response, buying the rest of the system room to recover.

What went down and what stayed up

At peak, about 20% of web and API requests failed, and roughly half of archive and raw-content downloads failed, according to GitHub's own numbers.

Why this matters if you've never opened GitHub

Construction AI Brief has covered a run of stories this month about contractors weighing whether to buy an AI vendor's product or build a narrower tool in-house — an open-source coding agent from DeepSeek, a price cut on Google's agent-building model, cheaper API access generally. GitHub Actions is the default place that homegrown automation ends up running: a scheduled job that pulls a spec section, matches it against a cut-sheet library, or reformats a daily log into a project-management format.

None of that is exotic anymore. A precon team that built a script to auto-flag missing submittal data before a bid deadline, or an ops group running a nightly sync between a scheduling tool and a shared spec library, is quietly dependent on GitHub staying up. This outage shows that dependency can fail for reasons that have nothing to do with the contractor's own code — a monitoring gap in someone else's data center, worsened by a bug in an editor plugin most people don't think of as backend infrastructure at all.

What still requires human judgment

An outage report is not a reason to avoid building internal tools — GitHub's own numbers put this well outside its normal availability, and the company has named specific fixes (correcting the autoscaling policy, tightening retry limits, auditing Istio concurrency settings, and fixing the VS Code bug). But it is a reason to ask, before wiring a deadline-sensitive process into any single vendor's automation: what's the fallback if that vendor is down for most of a workday? For a bid due at 2 p.m. or a submittal package due end of day, "wait for GitHub to recover" is not a plan. A person who can run the process manually, even slower, is the plan.

The takeaway

If your firm runs anything time-sensitive on GitHub Actions or through GitHub-hosted Copilot access, this outage is worth a five-minute conversation with whoever built it: what happens if this is down on a day it matters? The fix isn't switching platforms — it's making sure a single infrastructure failure two states away can't quietly become a missed deadline on your job.