Skip to content
On July 16, 2026, thousands of AWS customers were getting billing alerts originating from their Cost Explorer dashboards. Many were seeing estimated monthly spend a long the lines of $9 Billion up to the trillions! One account reportedly saw a projected month-over-month change of more than 55 trillion percent. AWS environments that consisted of solely a static s3 website were looking at a $5 billion estimate.
By morning, Reddit, X and LinkedIn were full of reports and screenshots, many of them in the midst of valid panic attacks. Aside from trying to contact AWS support, many claimed they never got any AWS email notifying them that this was perhaps some sort of error. Many even went so far as to stop and completely delete services due to lack of communication.
In the end, this was a display bug, not a billing event. Nobody paid a trillion dollars for anything, but it doesn’t mean there wasn’t any damage.
What actually happened with your AWS Billing
AWS traced the issue to a bug in the “estimated billing computation subsystem” behind Cost Explorer and the Billing Console. This came after an update and it multiplied turned normal, legitimate usage to show astronomical (and fictional) totals.
To their credit, AWS owned it fast and with a bit of humor. Their support account posted, “Slight miscalculation on our end (very slight 😅). We’re fixing it now. No action needed on your end. Sorry for the confusion. Real question: what will you do with those trillions instead?”
AWS’ painfully slow response and panic deletion that ensued
Although it was just a display issue and there was no actual billing affected, many customers couldn’t access their account. That means not only are they unable to see what went wrong, these customers weren’t getting any response to their support tickets. These tickets were being treated like a general 24 hour issue, rather than a real emergency.
AWS simply didn’t have any urgency to mitigate panic. This wasn’t an outage, data was not stolen, and there were no literal fires to put out. But many panicked faced with an unexplained multi-billion dollar estimate and no fast answer.
As a result, many AWS customers paused all of their services. Some even deleted, in the heat of the moment, multiple buckets, lambdas, S3 and even entire accounts. That means AWS’s poor safeguarding led to essentially self-inflicted downtime.
Panic that should be taken seriously
AWS’ response was humorous, sure. But this minimizes the real panic that hit so many desks that evening. So many forums talked about how their alarming billing alert meant they had to log a ticket and calculate their next move. That number has to go up the chain, to a manager, a CFO, maybe a board. That’s not a bug report anymore, it’s a career moment, a sleepless night wondering how they will explain what happened, all under their watch even though they did nothing wrong. That kind of panic doesn’t show up in any postmortem. That’s why so many people reached for the delete key instead of waiting for an answer.
Another glitch not on the bingo card
A few things that stood out as this mishap unfolded that once again, couldn’t have been on anyone’s radar.
A dashboard number is not a second opinion. Plenty of teams reacted to one screen with nothing to check it against. Would we? If a cost number looked insane tomorrow, is there an independent way to confirm “real or bug” before anyone touches infrastructure?
It doesn’t take an outage to cause one. Nothing in AWS’s infrastructure failed — this was a UI and estimation layer. But it produced outage-level behavior anyway: paused services, deleted resources, hours of scrambling. Which part of the stack breaks matters less than which part people trust blindly.
AI may have been in the financial loop and that means it’s still a liability. The more we let automation automate financials without a human sanity check, the more a single bug can cascade into real-world action. We’re not there yet on trusting this unsupervised, and this incident is a decent argument for why.
“Customer obsessed” isn’t what they say it is. Thousands of customers hit support at once. Many were simply waiting on an email. Everyone wanted a fast, human answer and when they didn’t get one, panic just became worse. t’s certainly fair that AWS was most likely overwhelmed with responses, but it’s a reminder that hyperscalers just simply cannot be as responsive even with a panicked customer base.
The downtime that mattered was self-inflicted. Nothing in AWS’s infrastructure failed. This was a UI and estimation layer, but it produced outage-level behavior anyway: paused services, deleted resources, hours of scrambling. Trust in ourselves easily goes out the window when there is no way to confirm what actually happened
The takeaway
No matter how much monitoring and how many safeguards we build, something will eventually surprise us. This is the nature of complex systems and it’s something we must expect to play out as we roll out more cloud complexity.
A few questions worth asking your own team, prompted by watching this play out:
- Do you have a second source of truth for monthly spend, something independent of the one AWS dashboard?
- Do you have a support relationship you can actually rely on when something looks broken?
- Do you know where your vendors have let AI into automated decision-making, and what happens when that input is wrong?
- Do you have a sanity check such as transparent reporting and visualization of cost anomalies before anyone reacts to a scary number?
- Are idle resources being automatically powered off, so “out of control spend” isn’t a plausible story in the first place?
Having real cost issues? Here’s our guide into fully understanding AWS costs and how to minimize them.