On 17 August 2026 GitHub was down for seven hours and forty-seven minutes. Authentication, Actions, the API, pull requests, issues and Copilot all went with it, and a large number of teams spent part of that afternoon working out whether their own build had broken.
That question - is this us or is this them - is worth being able to answer in two minutes rather than two hours, and the evidence that answers it disappears when the incident ends.
The evidence, in the order it helps
Which host is failing. Open the network tab and look at where the failing requests are going. A 500 from your own domain is yours. A 503 from an API you do not run is not, however much it looks like your feature is broken. This sounds obvious and is the step people skip, because the symptom appears in your interface and the interface is what they are looking at.
What the status code says. A 401 or 403 during somebody else’s authentication incident is not a permissions bug in your code, and it is the one most often misfiled as one. A 429 is a rate limit and may be a consequence of your own retries. A timeout with no response at all points outward more often than in.
Whether it correlates with your deploy. The first question in any incident channel is what changed. If your last release was three hours before the symptoms started, that is worth saying in the first message rather than the fifth.
What the status page says, checked second rather than first. Status pages are updated by people who are busy being on fire, and they lag the failure by a few minutes. Your own network tab knows before their status page does.
The trap: your retries can make it worse
The part of GitHub’s account worth reading twice is what happened during recovery. Their own postmortem says:
Errors in those services triggered a client-side retry loop that increased traffic during recovery. We had to mitigate that behavior before we could safely restore traffic.
So the clients trying hardest to get through were part of what kept the door shut. GitHub’s remediation list names the fix in general terms - “consistent retry limits, retry budgets, and variable timeouts across service-to-service interactions to prevent retry storms and cascading load” - and that is a sentence worth holding against your own code.
Retry logic written for a single failed request behaves differently when every request is failing. Without a budget, a backoff and some jitter, a hundred instances all retrying on the same schedule become a synchronised load test aimed at a service that is already struggling.
It is also worth knowing that neither of GitHub’s August incidents came from a code or configuration change. Both were capacity failures. The instinct to hunt for the deploy that caused it is usually right and was wrong here.
Capture it while it is broken
An outage is the one class of defect that repairs itself, and the evidence goes with it. Two hours later the request that returned a 503 returns a 200, and the ticket says “intermittent failure, cannot reproduce” for the rest of its life.
What you want, taken during the incident: the failing requests with their status codes and timings, the console output, and the time each one happened.
Session Replay
Free Chrome extension. One click on the page that is misbehaving captures the screenshot, the console and the network log, and hands you a link to paste into the ticket.
The network log includes a HAR file, which is the artefact somebody else’s support team will ask you for anyway. Sanitise it before sending it onward: a HAR saved with content carries session cookies and authorization headers, and it is the one thing about this workflow that has already caused a breach at somebody else’s company.
Writing it down so it is not misfiled
An incident report and a bug report are different documents, and confusing them wastes a developer’s morning.
If the failure is somebody else’s, say so in the title, and say what it means for you: which feature is affected, whether there is a workaround, and what you are waiting on. “Checkout failing - upstream payment provider returning 503 since 14:10, no workaround, their status page acknowledges it” is a complete report. Nobody needs to reproduce it, and nobody should try.
If it might be yours, it is an ordinary bug report and wants the ordinary things: what you expected, what happened, the environment, and the evidence. Our guide to writing one has the shape, and the ten common mistakes covers what usually goes missing.
And if you genuinely do not know yet, write that. “Unclear whether ours - failing requests are to an external host, but our release went out at 13:30” is more useful than a confident guess in either direction.
Afterwards
Two questions worth asking once the incident is over, while people still remember.
How long did it take us to know it was not us? If the answer is an hour, the fix is usually visibility rather than resilience: somewhere to look that shows which hosts are failing.
Did our retries help or hurt? GitHub had to mitigate client behaviour before they could restore traffic. Your clients are somebody else’s client behaviour.
Sources: GitHub’s own account of the incident is at The August 17 outage, and the work ahead, and it is unusually specific about what went wrong. Published to their credit, and quoted here because a postmortem that names retry storms is more useful than any advice about them.