On 17 August 2026, GitHub — the platform where much of the world's software lives — was down for 7 hours and 47 minutes. It wasn't an attack, it wasn't a virus, and it wasn't someone deleting the wrong file. It was a capacity failure: traffic hit a new peak and a critical component didn't keep up.
If your company doesn't write software, the news feels distant. It isn't. What happened there happens, on a smaller scale, to the management system you subscribe to, to the card reader, to the mail server and to your online store. This article answers one question: what does your company do during the hours when the system it depends on isn't there?
What happened to GitHub
The outage started at 13:28 and ended at 21:15 UTC, according to the company's own report. It took down the site, authentication, GitHub Actions, the APIs, pull requests, issues and Copilot. At peak, roughly 20% of web and API requests were failing, and archive and raw-content downloads reached 50% errors.
Translated for people outside the field: for almost eight hours, a large share of the world's technology teams couldn't ship anything. Anyone with a delivery scheduled that day didn't deliver.
The cause wasn't an attack or a bug — it was growth
This is the part that matters most to decision-makers. GitHub's report points to network saturation on the load balancers in the Central US data center, caused by a new traffic peak. There was no code change and no misconfiguration: demand outgrew what the infrastructure could take.
The numbers explain the scale. Since April, monthly commits on the platform jumped from 1.4 billion to 2.9 billion. Merged pull requests reached about 130 million per month and new repositories about 24 million per month. The company says it added more than 3 million CPU cores and 120 petabytes of high-speed storage, and now serves roughly 58% of platform load through Azure infrastructure.
In other words: the product's success caused the outage. It's the kind of risk nobody puts in the spreadsheet, because it doesn't look like a problem — it looks like good news. It applies to a global platform, and it applies to your company on the day the campaign works and the site gets ten times the usual traffic.
The most instructive detail: the automatic retry
When a system fails, the programs that depend on it usually try again by themselves. That sounds reasonable — and, done carelessly, it's what turns a failure into a long outage. In GitHub's case the report is explicit: the errors triggered a client-side retry loop that increased traffic during recovery and delayed Copilot's return.
Note the order: the automatic retry didn't cause the outage, but it got in the way of coming out of it. It's a technical detail with a direct practical consequence for any company with integrations — invoicing, billing, messaging, marketplace sync. The question for your supplier or whoever looks after your system is: when a call fails, does it retry immediately, and how many times? The right answer is to wait a little longer on each attempt and give up after a few — not to hammer.
Before the backup plan, the question almost nobody asks
The conversation about downtime almost always starts from the wrong end, with technology. It should start with the arithmetic: what does one hour of downtime cost, for each part of your business?
For an online store it's the average hourly revenue, plus the customers who don't come back. For a clinic it's the day's schedule. For a factory it may be almost nothing for a few hours — and catastrophic if it lands on month-end closing. Without that number, any discussion about redundancy becomes personal preference, and the decision ends up being made by the fright of the last incident.
The conclusion tends to be uncomfortable: most of a company's systems don't deserve a backup plan. Two or three do, and that's where the money should go.
The four levels of backup plan
From cheapest to most expensive. Pick the level based on the cost of downtime you just calculated.
1. The alert. Knowing it went down before the customer tells you. It's the cheapest level of all and the most ignored: an automatic check every few minutes that sends a message when the service doesn't answer. Without it, your downtime starts counting when someone complains.
2. Manual mode. The written agreement for how the team works without the system: write the order on paper, photograph the ticket, enter it later. It costs a sheet of paper and a conversation, and it's what saves operations in most short outages.
3. The cold alternative. A second copy of what matters that doesn't depend on the main supplier: the customer list exported every week, invoices kept outside the system, records in a file you can open on your own. It doesn't replace the system — it stops the outage from becoming a loss.
4. Hot redundancy. A second path ready to take over. It's the only level that truly removes downtime, and it's expensive: you pay for capacity that sits idle almost all the time. It's only justified when an hour of downtime costs more than the subscription to the second path.
What we learned taking our own system down
Two stories of our own, because continuity theory is easy to write and hard to practise.
The first: on 2 August, our augmented reality platform was down for about four minutes. The cause was a badly written command that emptied a file on the server. What shortened the outage wasn't any sophisticated technology — it was having kept a copy of the file before replacing it, and having the service configured to restart itself when it dies.
The second is worse, and it's the one that teaches most. We built a script that picks up the contacts sent through the site's form and emails them — and we forgot to schedule it. Nothing went down. No error screen, no alarm, the site responding normally. The contacts simply sat in a queue, waiting for a program that never ran.
The failure that frightens you is the one that takes the site down. The one that costs money is the silent one. That's why level 1 in the list above isn't "monitor whether the site is up", but "monitor whether the thing that makes money is happening": the order is arriving, the email is going out, the invoice is being issued.
How to decide, in four questions
Take this to your next conversation with whoever looks after your technology:
1. Which two or three systems stop the operation today if they're gone? 2. What does an hour without each of them cost? 3. How do I find out it went down — and how quickly? 4. Is there a written agreement for working without it that someone other than the owner has read?
If the fourth question has no answer, that's where you start: it's the cheapest of the four and the one that reduces the damage most.
When the answer runs through a system built to measure — because off-the-shelf can't handle your process, or because depending on a single supplier has become too big a risk — that's what we do: custom software development. And if the doubt is still between buying something ready-made and having it built, we've written about how to choose between custom software and an off-the-shelf system.
Sources
GitHub's official report on the 17 August 2026 outage ("The August 17 outage, and the work ahead"), published on the company blog. The figures for duration, affected services, error rate, commit volume and added capacity come from there.
Frequently asked questions
How long can my system be down without real damage?
There's no universal number — it depends on what an hour of downtime costs in your business. The way to find it is per system: average hourly revenue for a store, the day's schedule for a clinic, month-end closing risk for a factory. That number is what defines how much it's worth spending to shorten the outage.
Are backups and a backup plan the same thing?
No. A backup keeps your data and stops you losing what you already had. A backup plan is how the operation keeps running while the system is away. You can have perfect backups and still spend eight hours unable to serve anyone.
What is a status page and why does it matter?
It's the page where a supplier publishes whether their service is working. It matters because it shortens the time between the outage and your decision: instead of spending half an hour assuming the problem is yours, you confirm in a minute that it's the supplier's and switch to manual mode.
Is off-the-shelf software safer than having something built to measure?
Neither — the risk just moves. With off-the-shelf you depend on the supplier's capacity and priorities, and their outage is your outage. With custom software you control the infrastructure and the order of repairs, but you need someone accountable for it. The choice depends on which of the two risks your company manages better.
How do I know whether my integrations retry calls the wrong way?
Ask whoever looks after the system three things: how many times a failed call is repeated, whether the gap between attempts grows each time, and whether there's a limit after which it gives up and logs the error. Immediate, unlimited retrying is the pattern that turns a short failure into a long outage.
Is redundancy worth paying for?
Only when an hour of downtime costs more than the idle second path. For most small and mid-sized companies the first three levels — alert, manual mode and cold alternative — solve most of the problem for a fraction of the price, and that's where it makes sense to start.