Back to blog

The Five Stages of Cloud Grief

Every team goes through the same five stages the first time they really look at what is running in their cloud account. Here is how to recognize each one, and how to skip straight to acceptance.

Elisabeth Kübler-Ross described five stages people move through when facing loss: denial, anger, bargaining, depression, and acceptance. She was not thinking about AWS bills when she wrote that. But anyone who has opened Cost Explorer after a few quiet months, or finally audited what is actually running in their account, will recognize the shape of it immediately.

We have watched enough teams connect a cloud account and look at their real inventory for the first time to know this is not a coincidence. It shows up in the same order, almost every time.

Stage 1: Denial

Denial sounds confident. It shows up in standup as "we don't really have that much waste" and in Slack as "our tagging is actually pretty good." Nobody is lying. They genuinely believe it, because nobody has looked closely enough to be proven wrong.

  • "We tag everything" — nobody has audited that claim in over a year.
  • "It is a small account" — nobody has actually counted the resources in it.
  • "We would know if something was wasteful" — nothing exists that would tell them.

Denial ends the moment someone runs a real scan and the number of resources on screen is three or four times what anyone guessed. It is rarely subtle.

Stage 2: Anger

Anger is directed outward, at first. "Who created this?" becomes a genuine investigation. Someone runs git blame on a Terraform file that has not been touched in two years. Someone else asks in the team channel, half-joking, half-not, whether this is the same load balancer from "the incident."

The anger fades once the answer becomes clear: it usually was not one person, and it usually was not a mistake. It was several people, months apart, each making a reasonable call in isolation. Nobody is the villain. The account just accumulated decisions faster than anyone reviewed them.

Stage 3: Bargaining

This is the longest stage, and the one most cleanups die in. Nobody wants to delete something and be wrong about it, so everything gets a temporary reprieve instead of a decision.

  • "Let's leave it for now, just in case."
  • "I will ask in the channel first."
  • "We can deal with it after this sprint."
  • "It is probably fine."

A spreadsheet gets created with a "keep / maybe / investigate" column. The "maybe" column grows. The spreadsheet is still open three weeks later, untouched, which is how bargaining quietly turns into the original problem wearing a tracking sheet.

Stage 4: Depression (also known as: the invoice)

This stage has a specific trigger: someone multiplies a monthly number by however many months the thing has actually been running. Forty dollars a month does not sound like much, until it is forty dollars a month for fourteen months, times however many other things in the account look exactly like it.

The number is not really the low point, though. The low point is realizing that nothing about how the account works has actually changed, which means this same exercise is waiting again in another six months.

Stage 5: Acceptance

Real acceptance is not "we cleaned it up." That is stage four with better posture, and it decays back into stage one the moment everyone stops paying attention. Real acceptance is "we changed how this gets found," which is the difference between an event and a system.

In practice, that means the inventory stops living in someone's memory and starts living somewhere continuous, with rules that flag things like unattached volumes, unassociated Elastic IPs, or missing owner tags as soon as they appear rather than fourteen months later. We wrote about exactly how to build that loop in how to find unused AWS resources (and stop paying for them).

Acceptance also means treating ownership as part of the infrastructure, not an afterthought. A resource with an owner tag is a quick Slack message. A resource without one is an investigation. Teams that reach lasting acceptance usually fix that gap once, with a rule, instead of re-litigating it every cleanup cycle.

Skip straight to stage five

None of the first four stages are mandatory. They are just what happens by default when the only way to see your cloud account is to go looking for it manually, months after the fact.

Cloustral exists to shorten that loop: connect an AWS or Azure account, get a continuous inventory instead of a periodic guess, and let rules surface the findings before they turn into a fourteen-month invoice. If you are not ready to connect a real account yet, you can explore the same workflow with synthetic demo data first.

The stages of grief are optional. The bill is not.