AWS Outage Postmortem Lessons Your Provider Will Not Write

An AWS outage postmortem is the public write-up AWS publishes after a major service disruption, which AWS calls a Post-Event Summary. It explains what failed inside AWS and what AWS will change. We read each one closely, and it can never explain why our own systems failed the way they did.

That gap matters more as public write-ups become rarer. The last entry on AWS's summary page is the October 2025 DynamoDB event. Incidents since then reached customers through a company statement and another company's postmortem, or not at all.

In this post we cover when AWS publishes, what the October 2025 summary taught and could not teach, the incidents that never got one, and a five-step customer-side postmortem you can run after the next provider outage.

AWS Publishes a Post-Event Summary Only Past a Threshold

AWS states its rule on the Post-Event Summaries page. When an issue has "broad and significant customer impact" that fails a significant share of control plane calls or infrastructure, or comes from total power or significant network failure, AWS commits to a public summary after the issue closes.

That threshold is about AWS's footprint, not yours. An incident that hits one zone, one service or one region can stop your business while staying below the bar. We treat the absence of a summary as normal, not as a sign that nothing important happened.

As of 7 October 2026, the page lists the DynamoDB disruption dated October 19, 2025 as its newest entry, and the one before it is from July 2024. Here is how the recent incidents we track reached the public.

When	What happened	Public explanation
October 19-20, 2025	DynamoDB DNS failure in us-east-1 with knock-on EC2 and load balancer impact	Full AWS Post-Event Summary
December 2025	AWS Cost Explorer interruption in one region, linked in press reports to an AI coding tool	No summary, an Amazon statement disputing the reports
May 7, 2026	Cooling failure in a us-east-1 data hall that took instances and volumes offline	No AWS summary, a detailed postmortem from Coinbase

What the October 2025 Summary Told Customers and What It Could Not

The October 2025 summary is the most recent public AWS postmortem, and it is a good document. AWS traced the root cause to "a latent race condition in the DynamoDB DNS management system that resulted in an incorrect empty DNS record" for the regional endpoint, and it committed to specific fixes.

The timeline is the part we found most useful. Impact ran from 11:48 PM PDT on October 19 to 2:20 PM PDT on October 20, in three periods. DynamoDB DNS was restored by 2:25 AM, yet new EC2 launches failed until 10:36 AM, and some new instances had connectivity issues until 1:50 PM.

That gap carries the lesson for customers. Fixing the trigger took under three hours, and the systems built on top took most of a day to converge. We saw the same pattern in other providers' outages, which we wrote about in the stuck-state postmortem.

What the summary could not say is everything on your side of the boundary. It could not tell you which of your services called DynamoDB, why your failover did or did not trigger, how your retries behaved, or which customers felt it. Only your own root cause analysis answers those, because only you hold the logs and traces from your side.

The Incidents That Never Got a Public AWS Summary

The two later incidents show what happens when no summary arrives. Each one left customers to piece the story together from other sources.

In December 2025, press reports linked a 13-hour interruption to an Amazon AI coding tool. Amazon disputed that account, calling the interruption "the result of user error" and tracing it to misconfigured access controls rather than AI. Amazon described an extremely limited event affecting AWS Cost Explorer in one of its 39 geographic regions, and added mandatory peer review for production access.

In May 2026, the detailed public account came from a customer. Coinbase published a postmortem of its May 7 outage, which left most of its services unavailable or degraded for roughly eight hours. Chiller units failed in one data hall in us-east-1, and Coinbase's matching engine, a Raft cluster inside a single placement group, lost quorum when three of its five nodes went down.

Coinbase also reported a defect in the control plane of AWS's managed Kafka service that stopped partition leaders from being reelected, which stretched recovery further. Its closing is the line we would pin above every provider review, a standard that rests "entirely on whether we have built systems resilient enough to withstand one."

The Coinbase write-up is the model we would follow. It explains the provider's trigger in one paragraph and spends the rest on Coinbase's own design choices and what it will change.

A Five-Step Customer-Side AWS Outage Postmortem

We run the same five steps after any provider incident that touched us, even when the provider publishes nothing. The Google SRE book defines the goal well. "A postmortem is a written record of an incident, its impact, the actions taken to mitigate or resolve it, the root cause(s), and the follow-up actions to prevent the incident from recurring."

1. Map Every Service That Touched the Failed Dependency

We use tracing and dependency maps to list every service that called the affected AWS service, region or zone during the window, not only the ones that alerted. The useful finds are silent dependencies, such as a logging or auth call that quietly blocked a critical path.

2. Put Your Timeline Next to the Provider's

We line up our first alert, our first customer report, the provider's first status update, our mitigation and our full recovery. If our alerts fired well before the status page moved, our monitoring did its job, and the question becomes why our response did not.

Reconstructing that timeline from logs is the slowest step, and it is the step an AI agent that investigates with evidence can draft for a reviewer. Either way, every timestamp should link to the log line or graph it came from.

3. Audit Single-Zone and Single-Region Exposure

Coinbase's quorum loss came from placing a whole cluster in one placement group for latency, so a single facility problem took out most of it at once. We look for the same pattern in our own infrastructure code, such as databases, NAT gateways or caches pinned to one availability zone, and control-plane tools that only run in one region.

4. Record What Monitoring Saw, Missed and Misattributed

We note which dashboards turned red, which stayed green while users failed, and which alerts blamed the wrong component. Cached health checks that keep passing during a DNS failure are a common miss, and they belong in the write-up.

5. Assign Dated Actions With Owners

Each action gets an owner and a date, or it does not count. We aim for at least one architecture change, one monitoring change and one runbook change, and we review them at the next provider incident. We keep these records searchable, as we argued in postmortem records that answer questions.

Pitfalls That Waste a Provider Outage

Three habits turn a provider incident into lost learning. We check for each one in review.

• Trusting the status page over your own signals, when your latency and error graphs are the faster, more specific evidence.
• Treating the outage as an act of nature, when the provider failure was outside your control but your blast radius was not.
• Forgetting the control plane, when deploy tooling, identity or consoles in one region can tie you to that region even if your data lives elsewhere.

The first fifteen minutes of a provider outage need a different playbook from the postmortem. We cover deciding "is it us or the provider" in our upstream outage triage protocol, and the same thinking applies to AI model providers, as in the correlated model API outage.

When a Customer-Side Postmortem Is Not Worth Writing

We do not write a full postmortem for every provider blip. Two situations call for something lighter.

• The Outage Never Reached Your Users

If failover worked, no customer noticed and no alert misbehaved, a short note in the incident log is enough. We record what protected us, so nobody removes it later by accident.

• Nothing on Your Side Could Change the Outcome

Sometimes a dependency has no alternative and the impact was what any design would see. We still log the incident, then write a full review only when the same dependency hurts us a second time.

Write the AWS Outage Postmortem for Your Side of the Boundary

We would pick the last provider incident that touched you and run the five steps this week, starting with the dependency map. The actions it produces are worth more than any summary the provider writes.

An AWS outage postmortem from your own team turns someone else's failure into a list of changes you control. Assembling that evidence is the work Operate takes on. It brings the evidence from your logs, databases and code together through read-only adapters, and proposes any code fix as a patch file an engineer reviews and applies.