Skip to content
On July 16, 2026, a display bug in AWS Cost Explorer showed some customers cost estimates in the billions and even trillions of dollars. No one was actually charged, because the error sat in Cost Explorer’s forecasting display and not in AWS’s billing systems. The real damage came from the reaction, as some teams deleted resources in a panic and caused their own downtime.
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 the AWS Cost Explorer bug?
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.
AWS owned it, but not via email. They updated their Service Health Dashboard, and had a barely visible warning on their site that linked to it. They also applied a bit of humor to the situation, their support account posting, “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
Jokes aside, was anyone actually charged?
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.
Distress and panic it caused? Immeasurable.
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, valid services – 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, similar to what we saw during the AWS US-East-1 outage, likely weren’t 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.
The accounts that stayed calm had an advantage: any team with point-in-time backups and immutable snapshots could have restored a resource deleted in the panic within minutes, so a display glitch never had to become data loss. That is the practical takeaway. Recoverable backups turn an irreversible mistake into a quick restore, which is exactly what N2W automates with frequent point-in-time backups and immutable, cross-account copies.
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.
Frequently asked questions
A display error in AWS Cost Explorer. On July 16, 2026, Cost Explorer rendered wildly inflated cost estimates, some in the billions and trillions of dollars, because of a fault in its forecasting calculation. The billing and payment systems were never affected, so the figures on screen never reflected real charges.
No. The bug lived in Cost Explorer’s estimate and forecast display, not in AWS’s billing or payment systems. No customer was charged the inflated figures as AWS explained, “The displayed billing estimates do not reflect actual usage and charges.”
Customers reported projections from roughly $5 billion up to trillions of dollars. One account showed a month-over-month change of about 55 trillion percent. The sheer scale made it clear to most people that the estimates were a glitch, not a bill.
Check whether the number appears in Cost Explorer’s estimate or forecast view rather than your actual Bills page, and confirm against the AWS Health Dashboard before you act. Do not delete or shut down resources in a panic. Open an AWS Support case instead of making irreversible changes based on a projection.
The bug charged no one, but the panic caused real losses. Some teams deleted or shut down resources to stop a charge that did not exist, and caused their own downtime and data loss. The lasting lesson is that an irreversible reaction to a display error can cost far more than the error.