# Cost Is a Reliability Signal

> A spend spike is often the first sign that something is technically wrong.

Source: https://christwentyfour.com/blog/cost-is-a-reliability-signal

A sudden cost change is often the first sign that something is technically wrong. It can show up before your monitoring does.

## What a spike can mean

- A retry loop firing constantly. The requests are real and pointless.
- A debug log in a hot path, producing more ingest than value.
- An autoscaler buying its way around a regression. The system stays up and the graphs look fine, and you keep paying.
- Cross-zone transfer from something that moved.
- Storage growing without limit, because no lifecycle rule was set.

## Alert on change, not the monthly total

A monthly review arrives after you have paid for a month of the problem. Alert when daily spend drifts from its trailing average by a set margin, per service if your tags allow. False positives are cheap. Someone says "we launched that" and moves on.

Divide by traffic, so growth does not look like a leak:

$$\text{cost per request} = \frac{\text{daily cost}}{\text{daily requests}}$$

**Worked example:** **$20** per million requests · **$30** after the jump

At $400 a day and 20 million requests, you pay $20 per million requests. If spend jumps to $600 and traffic stays flat, it is $30 per million. That is a 50% jump with nothing to explain it. An alert at 25% over the trailing average ($500 here) would have fired.

## Tag at creation

Untagged spend piles up in "other," and nobody can see what changed in it. Put tags in the infrastructure code. Retroactive tagging projects do not stay finished.

## Right-sizing is reliability work

An oversized instance hides how the service behaves under pressure. An undersized one has no room for surprises. Cost is one input, not the only one.

Show each team what its service costs. Most engineers do not know, and most care once they find out.