Latent bugs wait for the right trigger
The defect had been live in production for nearly four weeks before any customer's configuration happened to activate it — a reminder that "no incidents yet" is not the same as "no risk present."
Case study · June 2021
One customer's config change broke a fifth of the web.
A single valid configuration change, pushed by one Fastly customer, triggered a five-week-old latent bug and knocked 85% of Fastly's network offline — taking Reddit, Amazon, Twitch, government sites, and major news outlets down with it, worldwide, at once.
Scroll for the timeline
49min
From detection to 95% recovered
85%
Of Fastly's network returning errors
Quick facts
What happened, in one table.
Fastly never disclosed a financial cost for this incident, which is itself worth noting — this case study is included for its speed-of-response lesson, not its dollar figure.
Date
June 8, 2021, from roughly 05:50 to 06:45 US Eastern time.
What broke
A software deployment on May 12 had introduced a latent bug that could only be triggered by a specific customer configuration. On June 8, one customer pushed a valid config change that happened to match those exact conditions, per Fastly's own summary.
Scale
Roughly 85% of Fastly's network began returning errors, taking down Reddit, Twitch, Spotify, PayPal, Shopify, Stripe, gov.uk, and major news outlets including CNN, the Guardian, and the New York Times — sites with no relationship to each other beyond sharing the same CDN.
Recovery
Fastly detected the disruption within one minute, identified and disabled the trigger, and had 95% of its network operating normally again within 49 minutes — among the fastest recoveries from a global-scale outage on this list.
Reported cost
No aggregate financial cost has been publicly disclosed by Fastly or independently estimated for this incident, unlike the other case studies here — a reminder that many high-visibility outages never produce a citable dollar figure at all.
Why it spread so fast
The bug was old. The trigger was new.
This incident shows both the risk of shared infrastructure and what a well-rehearsed incident response looks like.
One customer's action, everyone's outage
A single tenant's valid, permitted configuration change was enough to degrade the shared platform for every other customer — multi-tenant infrastructure needs blast-radius controls that don't rely on any one customer behaving conservatively.
Fast detection changes the whole cost curve
A one-minute detection time and a 49-minute recovery kept this incident short enough that no company involved appears to have disclosed a specific loss — proof that MTTR investment pays off exactly when it's needed most.
FAQ
Fastly outage, answered.
Questions that come up when citing this incident in a CDN-dependency or incident-response case.
Was this a cyberattack?
No — Fastly attributed it to a software bug triggered by a legitimate customer configuration change, not any external attack.
Why is there no cost figure for this incident?
Neither Fastly nor the affected customer sites have publicly disclosed a financial impact — the outage's short duration likely limited the incentive or need to quantify it publicly.
Why did so many unrelated sites go down together?
All of them used Fastly as their content delivery network, so a fault in Fastly's shared infrastructure affected every customer relying on the same affected capacity, regardless of each site's own reliability practices.
How would this map to the calculator?
Use the website downtime calculator with a short MTTR input to see how much a fast recovery limits total exposure even at large scale.
Your turn