GitHub's August 17 Outage: Agent Fleets Need a 4-Hour Local Fallback

Official Sources#

Last updated: August 21, 2026

For 7 hours and 47 minutes on August 17, the control plane a lot of coding-agent fleets now assume is always there ran hot and recovered in stages: github.com, authentication, GitHub Actions, APIs, pull requests, issues, and Copilot. If your merge path is "the agent opens a PR, Actions gates it, Copilot Cloud Agent is the worker," that path was the outage. A fleet that cannot keep producing local commits and reviewable diffs for about four hours is coupled to someone else's load balancer. GitHub's RCA is specific about how a capacity miss became a retry storm. Your agents can do the same thing.

What actually failed#

CTO Vlad Fedorov posted the company write-up on August 20. The status-page RCA is the technical record. The incident ran 13:28-21:15 UTC. At peak, web/API errors were about 20%, and archive and raw-content downloads about 50%. SAML/OIDC, SCIM, and Team Sync were hit, as were Actions workflows in GitHub Enterprise Cloud with Data Residency that depend on public workflow definitions hosted on github.com. Most services recovered at 16:36 UTC with the Central US datacenter. Actions stayed degraded until about 18:03. Copilot Token Service recovered at 21:02.

This was GitHub's second significant incident in August, after an Actions failure on August 6. Fedorov is explicit that neither was a bad deploy: both were capacity failures. Since April, monthly commits on GitHub have grown from 1.4 billion to 2.9 billion. Agent fleets are a big part of that curve.

The trigger was a new traffic peak that saturated load balancers in Central US. An Istio sidecar pod hit its concurrency limit. Autoscaling watched the host service, not the sidecar, so the sidecar did not scale. That cascaded until four HAProxy nodes exhausted their flow limits and the gateway auth path degraded. Optimistic retries then overloaded the load balancers.

Failed traffic moved to Northern Virginia and served there while Central US was debugged. Delayed replies to one internal endpoint triggered a latent VS Code retry bug that amplified traffic about 10x. Copilot Token Service went from a normal 7-9K RPS to 70-100K. Pausing HAProxy on those four nodes produced broad recovery. Residual Copilot auth failures continued because client retry loops would not let the token service drain.

GitHub also listed unrelated traffic spikes on codeload as a complicating factor. Recovery that actually ended the incident: pause the exhausted HAProxy nodes, cut gateway retries, and 403 inbound Copilot token requests until callers could be ramped back per site.

The Hacker News thread on Fedorov's post sat at 612 points and 708 comments. The argument that stuck is the SRE one: a large system is always both idle and overloaded, and the failure that matters is collapsing instead of shedding load. That is also the failure mode of an agent fleet that retries forever.

GitHub is the control plane now#

A GitHub brownout used to mean you merged later and ran tests locally. In 2026 a lot of teams have wired the forge into the agent runtime:

• Issues and draft PRs are how Copilot coding agent takes work and returns it.
• Actions is the merge gate and, for some repos, the only CI.
• Git worktrees isolate parallel agents, then those agents git push and open PRs as the handoff.
• Copilot in VS Code authenticates through the Copilot Token Service that spent the afternoon in a retry loop.

If that stack is yours, GitHub is the scheduler, the identity provider, the CI fabric, and the agent mailbox. Taking any of those away for four to eight hours does not pause the fleet. It turns the fleet into a retry generator. During recovery, Copilot via the GitHub CLI and the GitHub App stayed up while editor-side token auth did not. A local CLI agent and a cloud agent sitting on github.com are not the same dependency.

A 4-hour local fallback#

Most of the platform was back around 16:36 UTC, roughly three hours in. Actions lagged until about 18:03. Copilot tokens lagged until 21:02. Four hours is the window you should be able to keep working without github.com, PRs, Actions, or Copilot Cloud Agent.

Keep git and a local agent working with the network unplugged. Claude Code and OpenCode already run against a working tree. Point them at a worktree, keep tests and typecheck local, and write commits that do not need a remote. If you want a forge in that window, run one on the LAN, or just use a bare repo on a box you own. You need git log, git diff, and a place to park branches until github.com answers again. The OpenCode developer guide is the longer CLI tour.

Do not queue 200 Copilot Cloud Agent tasks as the only merge path. Cloud Agent is a GitHub-native worker: issue in, draft PR out, session logs on github.com. That is a strong default on a healthy day and a single point of failure on August 17. Cap the cloud queue. Keep a local CLI path that can finish the same slice and leave a branch you push later.

Pin Actions to reusable workflows you host. The RCA called out GHEC-with-Data-Residency workflows that depend on public workflow step definitions on github.com. If your reusable workflow lives only on the public site, a github.com outage is a CI outage even when your runners are fine. Keep the YAML in an org you control, pin third-party actions by SHA, and make sure the real gate still runs on a laptop.

Treat retry storms as a client bug. GitHub's optimistic retries overloaded its own LBs. VS Code's latent retry bug multiplied Copilot token traffic by ten. Your fleet will do this if a 502 from api.github.com becomes "retry immediately, then retry the retries." Fail closed on forge operations: cap attempts, add jittered backoff, stop on 403/429, and keep coding locally. Do not let 50 worktrees hammer pull-request APIs because the status page is red.

A fallback is not a second GitHub. It is a rule: for four hours the unit of progress is a local commit plus a passing local gate, not a green check on a PR you cannot open.

A separate reminder, three days later#

This was not the last Copilot Cloud Agent blip of the week. On August 20-21 GitHub posted a separate incident for Cloud Agent task-status visibility: newly started tasks did not show progress, session output lagged by about an hour, and the tasks themselves still completed. That is not the August 17 event. It is the same tell. If the only way you know work finished is a card on github.com, you are one visibility bug away from a silent queue.

As of August 21, 90-day uptime on the status page is 99.33% for Actions and 99.64% for Copilot. Those are not bad numbers. They are also not "always there."

What GitHub said it will change#

Fedorov's post and the RCA line up. Immediate work includes consistent retry limits, retry budgets, and variable timeouts. The RCA follow-ups: fix sidecar autoscaling so it watches sidecar concurrency, audit Istio limits, review retry and backoff on gateways and clients, address the VS Code retry behavior, and improve load-balancer monitoring and regional failover. That list is GitHub's. The client-side half is yours.

FAQ#

How long was the GitHub August 17, 2026 outage?#

Seven hours and 47 minutes, 13:28-21:15 UTC. Most services recovered by 16:36 UTC, Actions around 18:03, Copilot Token Service at 21:02.

What caused the GitHub August 17 outage?#

Network saturation on Central US load balancers after a new traffic peak. An Istio sidecar hit concurrency limits and did not autoscale (policy watched the host, not the sidecar). Four HAProxy nodes exhausted flow limits and degraded gateway auth. Optimistic retries overloaded the LBs. A latent VS Code retry bug amplified Copilot token traffic about 10x, from 7-9K RPS to 70-100K.

Did GitHub Actions and Copilot both go down?#

Yes. Actions recovered around 18:03 UTC, Copilot Token Service at 21:02. During that tail, Copilot via the GitHub CLI and GitHub App was unaffected. Keep a local CLI agent in the fallback path.

What should a coding-agent fleet do when GitHub is down?#

Keep producing local commits and local test proof for at least four hours. Use worktrees plus a local CLI agent. Do not make Copilot Cloud Agent, github.com PRs, or Actions the only merge path. Pin reusable workflows in an org you host, and cap retries.

Was the August 20-21 Copilot Cloud Agent incident the same outage?#

No. August 17 was the 7-hour, 47-minute Central US load-balancer failure. August 20-21 was a separate Copilot Cloud Agent visibility problem: task status lagged about an hour, while the tasks still completed.

What is GitHub Actions and Copilot 90-day uptime after this?#

As of August 21: Actions 99.33%, Copilot 99.64% over 90 days. Plan for a multi-hour hole.

Sources#

• The August 17 outage, and the work ahead - GitHub Blog (Vlad Fedorov, Aug 20, 2026). Fetched August 21, 2026.
• Incident with GitHub.com - GitHub Status. Fetched August 21, 2026.
• Intermittent failures creating agent tasks - GitHub Status. Fetched August 21, 2026.
• GitHub Status - Actions 90-day uptime 99.33%, Copilot 99.64% as of August 21, 2026.
• The August 17 outage - Hacker News - 612 points, 708 comments. Fetched August 21, 2026.
• OpenCode Go - referral signup for a local CLI that does not need github.com to start a session (code M6HEHM4JM5)

Some links to tools above are referral links - see our affiliate disclosure.

Continue Reading#

• GitHub Copilot Coding Agent and CLI - the GitHub-native issue-to-PR worker this outage took off the board
• Claude Code Worktrees - local isolation so a fleet can keep writing when the remote is gone
• OpenCode Developer Guide - a terminal agent that does not need github.com to start a session
• Claude Code vs Codex vs Cursor vs OpenCode - which runtimes are local-first versus forge-native
• Claude Code token overhead vs OpenCode - why chatty clients and fat retries get expensive when the network is already sick