Amazon Bounces Back From Outage as User Complaints Drop Significantly, According to Downdetector

Correction: Amazon contacted us to say this report was not accurate and that the company had no outage. Our original version described a confirmed Amazon outage on Wednesday, 5 November. We could not support that claim, and it has been removed. What remains below is limited to the record: a spike in reports on a third-party tracker, Amazon's statement that its services were running normally, and the distance between those two things.

Downdetector, the crowd-sourced outage tracker, logged more than 6,000 user reports against Amazon on Wednesday afternoon in the United States. The count fell back under 1,000 not long after, which is what Reuters described as a broad restoration of access. Reports clustered in New York, Los Angeles, Chicago, Detroit and St. Louis. Amazon Web Services, the cloud arm, drew a far smaller number of reports over the same window.

Amazon does not agree that anything went down. An AWS spokesperson told Reuters that "AWS services are operating normally." No statement acknowledging a retail-side failure followed, and the company has since told us directly that no outage took place.

What a report spike proves, and what it does not

Downdetector works by counting complaints. It aggregates user submissions and social signals, compares the volume against a baseline for that time of day, day of week and location, and flags the spike when it clears a threshold. That makes it fast. It does not make it a measurement of availability.

The gap is arithmetic. Downdetector knows how many people complained. It does not know how many people were using Amazon at that moment, so it has a numerator and no denominator, and it cannot produce an error rate from that. Six thousand reports against a site that serves millions of sessions an hour is a signal worth chasing. It is not, on its own, evidence that the site was down.

The category breakdown pointed the same direction. The bulk of the reports named checkout and the shopping cart rather than the site failing to load — one path in one flow, not a storefront going dark. Amazon's own AWS Health Dashboard remains the authoritative record for the cloud side, and it is the source Amazon points to when third-party trackers light up.

Why October made a small spike look like a large one

Two weeks earlier, AWS had a genuine failure, and a severe one. Starting late on 19 October, the us-east-1 region in Northern Virginia broke for roughly fifteen hours. In its post-event summary, AWS traced it to a race condition in the automation that manages DynamoDB's DNS records: two components collided, one applied a stale plan while the other's cleanup deleted it, and the regional endpoint was left with an empty record that the automation could not repair on its own. Operators had to intervene by hand.

The blast radius went well past DynamoDB — EC2 launches, Network Load Balancer connections, STS, the management console — and out into Snapchat, Roblox, Fortnite and Coinbase. It restarted an argument that had been running for years about how much of the internet sits on one region of one provider.

That is the context Wednesday's numbers landed in, and it is where we went wrong. A few thousand complaint reports two weeks after a fifteen-hour cloud failure read as the beginning of a second one. We treated a tracker spike as a confirmed incident because the previous incident had been real.

What confirmation would have required

Reporting an outage takes more than a report count: an acknowledgment from the company, an entry on its status dashboard, or independent measurement showing failed requests. None of those existed here. Amazon says its services ran normally, and nothing on the record contradicts that.

Trackers like Downdetector are still worth watching, because complaint volume moves before a status page does. The error is treating the early signal as the finding. On Wednesday it was the signal, the finding never arrived, and we published anyway.