Should CDN Vendor Postmortems Follow the Same Blameless Format as Internal Incident Reviews?
Same spirit, different job. A CDN vendor's report is already blameless toward people: the public reports from Cloudflare, Fastly, Akamai and Microsoft's Azure Front Door name no engineers and take the blame as a company. But that report is written for thousands of customers and checked before it goes out, while your internal incident review exists so your own team can learn.
So don't expect the vendor's document to work like your blameless postmortem, and don't try to force it into that shape. Read it as one input, push the vendor for the details it leaves out, then run your own review of how your stack handled their failure.
Why Blameless Postmortems Became the Standard for Internal Incident Reviews
The idea is older than most SRE teams. Google's SRE book traces blameless culture back to healthcare and aviation, where hiding mistakes gets people killed. In tech, John Allspaw's 2012 Etsy post made the case that engineers will only give a full, honest account of what they did and assumed if they aren't punished for it.
Blameless doesn't mean nobody is accountable. Allspaw was clear that engineers stay on the hook for fixing things. The book describes a blameless postmortem as one that looks for contributing causes without indicting any person or team, and it frames writing one as a learning opportunity rather than a punishment. Atlassian's handbook adds a simple habit worth copying: refer to people by role, like "the on-call engineer," instead of by name.
A typical postmortem template, like PagerDuty's, covers:
- What happened, and a timeline of it
- Contributing factors and how it was resolved
- Customer impact
- What went well, what didn't, and action items with owners
The classic SRE postmortem also has clear triggers, such as user-visible downtime, data loss, a long resolution time or a monitoring failure that left humans to spot the problem.
How CDN Vendor Postmortems Differ From Internal Incident Reviews
Here's how I'd put the two side by side:
That management review is real. Cloudflare's former incident policy said its reports were reviewed by management for "content, commitments and professional presentation" before release. That's not a bad thing. It just means the document is curated, and some of what you need won't survive the edit.
Vendors also own failures at the company level. Cloudflare called its June 2025 outage "a failure on our part," and Fastly said of its 2021 bug that it should have anticipated it. Even when a customer's config change set things off, as in Fastly's 2021 outage and Azure Front Door's October 2025 one, both reports described that change as valid. That's blameless thinking, pointed outward.
The Information CDN Vendors Typically Include and Leave Out of Postmortems
The good news is that the big public reports are detailed and fast. Fastly published its June 2021 report the same day, and Cloudflare's reports for its November and December 2025 outages also came out the same day. They usually include:
- A minute-level timeline
- The root cause in technical terms
- Aggregate impact, like Fastly's note that 85% of its network returned errors, or Cloudflare's figure that 90.22% of Workers KV requests failed in June 2025
- A list of remediations
What you almost never get is your own story. None of these reports covers per-customer impact, which of your requests failed or how SLA credits work. Upstream vendors often go unnamed too: Cloudflare's June 2025 report blamed a "third-party cloud provider," and you had to read Google Cloud's own report to see its outage started three minutes earlier.
Plenty of incidents never get a public write-up. AWS publishes Post-Event Summaries only for broad, significant impact, and Azure posts public reviews only for wide incidents, sending the rest to affected customers privately.
How to Get More Useful Information Out of a CDN Vendor Postmortem
You'll get more if you ask early and ask specifically:
- Open a support ticket asking for a root cause analysis tied to your account, with affected regions and time windows.
- Ask what the vendor saw for your traffic, not the whole network: error rates, the PoPs involved, any related config changes and when they detected the problem.
- Bring your evidence. Your request logs and error codes make the conversation concrete.
- Get RCA timing into your contract. None of the public CDN SLAs I checked from Cloudflare, Fastly, Amazon CloudFront or Akamai promises an RCA deadline. Microsoft says it generally shares a preliminary review within 72 hours and a final one within 14 days, so that's a reasonable benchmark to negotiate toward.
- Ask whether the promised fixes actually shipped. Follow-ups are rare, but they exist: Cloudflare's May 2026 "Code Orange: Fail Small" update said its new deployment safeguards would have avoided both late-2025 outages. I'd ask for that kind of closure on every incident that hit you.
Watch the credit clock too, because it starts ticking during the outage:
How to Run Your Own Postmortem Alongside the CDN Vendor's Report
This is where your incident management process earns its keep. Atlassian's incident handbook has a neat pattern for vendor outages: record the vendor fault as the proximate cause, get the vendor's postmortem, then keep digging for the root cause on your side.
Run it blameless, and ask questions the vendor can't answer for you:
- Did your monitoring catch it before the vendor's status page did?
- How long did it take to decide to fail over, and did the runbook work?
- Did your real user monitoring and CDN logs show which users and regions suffered?
- Was this CDN a single point of failure for anything critical?
That last question matters more than it sounds. Uptime Institute has found that third-party providers account for about two-thirds of publicly reported outages over nine years. You can't make a vendor's postmortem better, but you can make their next outage smaller for you. Action items like automated failover and zero-downtime deployment across multiple CDNs come out of your review, not theirs. File the vendor's report as evidence in your own postmortem, not as its conclusion.