GitHub was down for seven and a half hours. The lesson isn't about GitHub

If you run a Shopify store, yesterday’s GitHub outage did not touch your checkout, your subscriptions or your subscribers. Your store kept selling for the entire seven and a half hours. There is no reason to check anything.

It is still the most useful outage of the year to read about, for two reasons. The first is that GitHub sits underneath the software supply chain that produces every app in your admin, so an outage there is a delay in your world even when nothing in your world breaks. The second is more specific, and it is buried in GitHub’s own status updates: one of the mitigations that helped was turning retries off. Anyone who runs recurring billing has a retry system too, and it fails in exactly the same shape.

This post covers what actually happened, what GitHub has and has not said, and the parts that transfer.

Quick answer: what happened to GitHub on 17 August 2026

GitHub declared an incident at 13:40 UTC on Monday 17 August 2026 and resolved it around 21:15 UTC — roughly seven and a half hours. At peak, GitHub reported “high error rates around 20% for web experiences and api traffic”, with “archive downloads and raw repository content downloads … experiencing an approximate 50% error rate” (GitHub community incident thread).

• Affected: Pull Requests, Issues, Actions, Webhooks, API Requests, Git Operations, Pages, SAML and OIDC authentication, SCIM, Team Sync, and Copilot.
• Root cause: not disclosed. GitHub said it had “identified the problematic component and … taken corrective actions”, and that a detailed root cause analysis would follow (InfoWorld).
• Notable mitigation: GitHub “partially disabled authentication token retries and … seen improvement”.
• Shape of the failure: partial, not total. One request in five failing is a different problem from a site being offline, and a worse one to diagnose.

The timeline

Sources: GitHub community incident thread, InfoWorld, BleepingComputer, Engadget. Retrieved 18 August 2026.

Two details in that table are worth sitting with. Recovery took nearly five hours after the problematic component was identified — finding the fault is the fast part. And Copilot stayed broken after the other seven services were mitigated, because authentication was the last thing to come back; developers in VS Code, Visual Studio and JetBrains IDEs were still failing to authenticate long after github.com looked fine again.

What GitHub still hasn’t said, and one clue it did give

There is no published root cause yet, and it would be wrong to invent one. GitHub publishes monthly availability reports, and that is where the analysis is likely to appear.

What is on the record is context, and it is unusually candid. GeekWire reported that GitHub’s infrastructure is under sustained strain from a surge in AI agent activity: CTO Vladimir Fedorov said the company had planned to expand capacity tenfold and by February concluded it needed roughly thirty times its current scale, with Microsoft attributing the pressure to the spike in AI agent development and GitHub accelerating its Azure migration and renting AWS capacity in response (GeekWire).

That is a growth-shaped failure, not a neglect-shaped one. Which is the version that catches competent teams.

And then there is the retry line. GitHub partially disabled authentication token retries and saw improvement. Retries are a resilience feature — when a request fails, try again — and under a partial failure they invert: every client that fails retries, retry traffic lands on the component that is already struggling, and the system that was designed to absorb failure starts manufacturing it. This is a well-understood failure mode, and it is the one thing in this incident that maps directly onto a subscription programme.

Why this matters to a merchant who has never opened GitHub

1. Your vendors’ ability to ship a fix is a dependency you never signed up for

Nothing in your store runs on GitHub. But the app that runs your subscriptions is built, reviewed, tested and deployed through it. For seven and a half hours yesterday, a large share of the world’s software teams could not merge a pull request or run a CI pipeline reliably.

If you had a bug open with any app vendor yesterday, that is where your fix was. Not lost — delayed. It is worth knowing that this category of delay exists, because the honest version of “we’re on it” on a day like that is “we’re on it, and our deployment pipeline is returning 503s.”

2. Partial failure is the normal failure mode, and it looks like your fault

A 20% error rate is the hardest kind of incident to read from the outside. Four in five things work. The status page may still say operational for the component you care about. What you see is not “the platform is down” — it is one weird failure, then another twenty minutes later, and a growing suspicion that you broke something.

The merchant version of this is a run of billing attempts failing on a morning when nothing changed. The instinct is to go looking through your own settings. The correct first move is to check the timestamps against your app’s and Shopify’s status pages, because an infrastructure blip and a configuration mistake produce nearly identical symptoms and only one of them is worth acting on.

3. The retry lesson transfers exactly

Dunning is a retry system pointed at card networks instead of servers. It has the same failure mode and the same fix: retry deliberately, back off, and stop when retrying is doing damage.

The economics already say so. Recurly’s network data shows 90% of recovered transactions occur within the first 10 days of a failed payment, so a sequence stretching over six weeks is spending most of its attempts on the flat part of the curve. And Shopify sets a hard ceiling — avoid re-billing a failed payment with the same customer payment method more than 30 times in 35 days, or the requests fail and the payment method is revoked. That is the retry storm in miniature: retries aimed at recovering a payment eventually destroy the payment method you were trying to charge.

The design that works is the same one GitHub reached for under pressure. Retry what can plausibly succeed on a later attempt, stop retrying what cannot, and treat aggressive retrying as a cost rather than as effort. The full breakdown of which Shopify error codes belong in each bucket is in how to recover failed subscription payments on Shopify.

4. Webhooks fail quietly, and quiet failures are the expensive ones

Webhooks were among the affected services. Webhooks are how systems tell each other that something happened, and when they fail, nothing raises its hand — the message simply never arrives, and both sides carry on believing the other is up to date.

This is worth one question to whoever runs your subscription app, and it is a fair question to ask any vendor: when a webhook fails to deliver, what happens? Good answers involve retry with backoff and a way to replay missed events. The answer you do not want is a shrug, because the merchant-visible version of a dropped webhook is an order that never got tagged, a subscription whose next billing date is wrong, or a cancellation that did not propagate — problems that surface days later as customer complaints rather than as errors.

What to actually do when a platform you depend on goes down

Not GitHub specifically — Shopify, your payment gateway, your 3PL’s API, your subscription app. The sequence is the same, and most of the value is in what you don’t do.

1. Confirm it before you act. Check the provider’s own status page, not social media. Downdetector-style report counts tell you people are annoyed, not what is broken.
2. Stop changing things. Do not reconfigure settings, manually retry payments or trigger a bulk action mid-incident. Every change you make becomes indistinguishable from the outage, and you will spend the next week unpicking which was which.
3. Write down the start time and three concrete examples. Order numbers, subscription IDs, timestamps. This is what makes reconciliation possible afterwards, and nobody can reconstruct it from memory.
4. Say something short to customers only if they can see it. If checkout is fine, say nothing. Announcing an outage your customers were never going to notice creates the doubt it was meant to prevent.
5. Reconcile after the incident closes, not during. Which billing attempts failed inside the window? Which of those are transient codes worth re-running rather than dunning? Did any webhooks not land? That is the real work, and it is all post-incident.
6. Read the postmortem when it comes. Not for the technical detail — for whether the vendor publishes one at all. A company that explains its failures in public is a company you can plan around.

The question worth asking your app vendors this week

While the incident is fresh and you have a reason to bring it up, four questions separate vendors who have thought about failure from vendors who have not:

• Is there a public status page and incident history? Not a support inbox. A page you can check at 7am without asking anyone.
• What happens to a billing attempt that fails because of an infrastructure error, not a card error? Does it get classified separately and re-run, or does it enter the dunning sequence and email the customer about a card that was fine?
• Are missed webhooks retried and replayable? And can support tell you which events were missed for your store during a given window?
• Do you publish postmortems? GitHub’s are public. Most subscription apps’ are not, and that asymmetry tells you something about which failures you would find out about.

None of these are reasons to switch apps. They are reasons to know what you have — which is the same argument as in platform risk after the Skio acquisition: the moment to understand your dependencies is a quiet Tuesday, not the morning they matter.

Where Curobi fits

Curobi is a Shopify subscription app, so read this section as what our product does rather than as neutral advice — everything above applies whichever app you run.

The part of this that is a product decision rather than a philosophy is error classification. Curobi’s failed-payment recovery reads the error code before deciding what to do with a failed billing attempt, so transient infrastructure failures and broken cards are not treated as the same event, and subscription analytics reports involuntary churn separately from voluntary churn so a bad hour on somebody’s infrastructure does not read as subscribers leaving.

We are pre-launch and we have not been tested by a seven-hour incident. No app has an honest claim to make about reliability it has not yet had to demonstrate, and any vendor telling you otherwise is describing an intention.

Frequently asked questions

1Was GitHub down on 17 August 2026?

Yes. GitHub declared an incident at 13:40 UTC on Monday 17 August 2026 and marked it resolved at roughly 21:15 UTC, a disruption of about seven and a half hours. At its peak GitHub reported high error rates of around 20% for web experiences and API traffic, with archive downloads and raw repository content downloads at an approximate 50% error rate. Pull Requests, Issues, Actions, Webhooks, API requests, Git Operations, Pages, SAML and OIDC authentication, SCIM, Team Sync and Copilot were all affected at some point during the incident.

2What caused the GitHub outage?

GitHub has not published a root cause. Its status updates said only that it had identified the problematic component and taken corrective actions, and the company said a detailed root cause analysis would be shared as soon as it was available. One published mitigation is informative even without the full analysis: GitHub said it had partially disabled authentication token retries and seen improvement, which indicates retry traffic was contributing to the load during recovery. Separately, GeekWire reported that GitHub has been under capacity strain from a surge in AI agent activity, with CTO Vladimir Fedorov saying the company had planned to expand capacity tenfold and by February concluded it needed roughly thirty times its current scale.

3How long was the GitHub outage?

About seven and a half hours end to end. The incident opened at 13:40 UTC, Copilot began showing degraded availability at 14:31 UTC, GitHub said it had identified the problematic component at 16:36 UTC, API operations returned to normal around 19:01 UTC, authentication issues were resolved around 20:45 UTC and the incident was marked resolved around 21:15 UTC. The window in which most services were visibly broken was shorter than the total incident length, which is typical: recovery takes longer than failure.

4Did the GitHub outage affect Shopify stores or subscription billing?

No. This was an outage of GitHub’s own services, and Shopify storefronts, checkout and subscription billing do not run on GitHub. No linked Shopify incident was reported alongside it. The indirect effect is on the software supply chain rather than on live commerce: while GitHub is degraded, the teams who build the apps in your store cannot merge, test or ship code normally, which is why an outage like this can delay a fix you are waiting on even though nothing in your store broke.

5What should a merchant do when a platform their store depends on goes down?

Confirm it is real before acting, using the provider’s own status page rather than social media, then stop making changes. Do not reconfigure settings, retry payments manually or start a migration during someone else’s incident, because you will not be able to tell your changes apart from the outage. Note the time the problem started, capture a few concrete examples such as order numbers or subscription IDs, tell customer support what is happening in one sentence, and wait for the incident to close before deciding whether anything was actually lost. Reconciliation, not intervention, is the work — and it happens afterwards.

6Can an upstream outage cause failed subscription payments?

It can cause billing attempts to fail for reasons that have nothing to do with the customer’s card. On Shopify, a failure of that kind typically returns a transient code such as TRANSIENT_ERROR, PROCESSING_ERROR or PAYMENT_PROVIDER_ERROR rather than a card-specific one like EXPIRED_CARD. That distinction matters, because a dunning sequence that treats an infrastructure failure as a payment problem will email subscribers asking them to fix a card that was never broken. Classify by error code before any customer-facing message goes out, and check whether a spike in declines lines up with an incident window before reading it as churn.

The takeaway

The GitHub outage is not a story about GitHub being unreliable. Seven and a half hours across a platform that carries most of the world’s software is a bad day, not a pattern, and the reported cause of the strain — demand growing faster than capacity could be added — is the failure mode that arrives with success.

What transfers to a subscription programme is smaller and more useful than “have a backup plan”. Partial failure is the normal kind, and it looks like your own mistake. Retries are the thing that turns a small failure into a large one, in infrastructure and in dunning alike. Quiet failures — a webhook that never arrives, a billing attempt that failed for an infrastructure reason and got dunned as if it were a dead card — cost more than loud ones, because nobody goes looking for them.

And the vendor question worth asking is not “will you ever go down”. Everyone goes down. It is “what will I be able to find out afterwards”.

Sources: GitHub community incident thread, 2026-08-17, GitHub Status, InfoWorld: GitHub restores services after nearly 8-hour outage, BleepingComputer: Microsoft confirms GitHub is down worldwide, Engadget: GitHub was down for most of the day, GeekWire: GitHub outage disrupts developers worldwide, Shopify SubscriptionBillingAttemptErrorCode reference, Shopify: build a subscription contract, Recurly: failed payment recovery data. All retrieved 18 August 2026.

Related reading: how to recover failed subscription payments on Shopify for the error-code classification this post refers to, failed payments are quietly costing you subscription revenue for why involuntary churn hides, and Skio is now part of Recharge for the other kind of platform risk.