Three real production outages from the last few weeks — two at GitHub, one at Cloudflare — each one worse than it needed to be. Short takes, not full breakdowns, so this can run on the weeks a full deep-dive doesn't fit.
GitHub: Retry Storm Amplified a Capacity Failure
Traffic hit a new peak, a critical component in GitHub's Central US data center failed to scale with it, and a client-side retry loop made recovery worse — GitHub had to throttle retrying clients before it could safely restore traffic at all. The outage ran 7 hours 47 minutes; the fix list leads with consistent retry limits, retry budgets, and variable timeouts across service-to-service calls.
https://www.digitalapplied.com/blog/github-august-17-outage-postmortem-retry-amplification
GitHub Actions: Two Unrelated Bugs, One 10-Hour Outage
A routine deployment to an internal Actions service exposed a latent capacity/concurrency weakness, cascading across clusters — then a second, separate bug let runners retry already-invalid jobs indefinitely. At peak, 71% of workflow runs saw infrastructure failures, over a 10 hour 42 minute incident.
https://blog.incidenthub.cloud/github-actions-pages-outage-aug-6-2026
Cloudflare: A Status Page Says Resolved, a Customer Says Otherwise
A bursty week — 13 separate status-page incidents between August 7 and 14, only one major: a roughly two-hour R2 write-availability problem affecting a small number of buckets in Cloudflare's Eastern North America region. Cloudflare's public status now marks the incident resolved, and recovery for most buckets came within about a day — but at least one customer has reported a bucket named "comfy-storage" with roughly 67GB still unrestored days later, flagged on Cloudflare's own community forum, with no formal postmortem from Cloudflare confirming or ruling out permanent data loss as of August 15.
https://shattered.io/cloudflare-outage-august-2026/
The Pattern: Retry Logic That Makes Things Worse
Two of three failures weren't the original problem — they were the retry behavior on top of it. GitHub's August 17 outage needed active client throttling before recovery could even start. GitHub Actions' August 6 outage had a second, independent retry bug compounding the first failure. If your own incident reviews only ask "what broke," and never "what did our own retry logic do once it broke," you're reading half the postmortem — the same half-the-postmortem problem we wrote about in Postmortems Without Teeth: naming the failure mode is easy, building something that actually stops it from recurring is the part most reviews skip.
What's the last incident on your team where the retry logic made things worse than the original failure?