Cloud spend is never perfectly flat. It moves with the calendar, with deploys, with traffic, with a dozen ordinary things that have nothing to do with a problem. The hard part of anomaly detection isn't spotting a spike, spikes are easy to spot. It's deciding which ones are worth anyone's time.
Why "the bill went up" isn't an anomaly
A month-over-month increase on its own says almost nothing. Spend goes up when a product launches, when a team ships a feature that does more compute, when a customer base grows. All of that is expected, often even good news. Calling every increase an anomaly is how alert fatigue starts, and alert fatigue is how a real spike eventually gets ignored along with all the noise.
Three things that look like anomalies but aren't
- Day-of-week and seasonal patterns. A B2B product's compute cost dropping every weekend isn't a problem, it's a rhythm. Flagging it as an anomaly every Monday just trains people to dismiss the alert.
- A known, planned change. A deliberate scale-up ahead of a launch, a deliberate migration, a deliberate new reserved capacity purchase. The cost moved because someone made it move on purpose.
- Gradual drift. Slow, steady growth over months is a trend worth watching, not a spike worth an incident. Trend and anomaly need different responses, one is a roadmap conversation, the other is a same-day investigation.
What actually makes a spike worth investigating
A real anomaly is a change that breaks the pattern the data itself has already established, not just a number that looks big. That means the baseline has to account for normal seasonality and day-of-week rhythm before anything gets compared against it. A spike that's unusual relative to last Tuesday, not last Monday, is a very different signal than one compared against a flat average.
The other marker of a real anomaly: it's usually traceable to something specific once you drill in, a particular subscription, a particular service, a particular meter. Noise tends to be diffuse, a little higher everywhere. Signal tends to be concentrated, a lot higher in one specific place.
Severity isn't the same as size
A $50,000 increase on a $2,000,000 monthly bill and a $50,000 increase on a $60,000 monthly bill are not the same event, even though the dollar figure matches. Severity needs to be relative to the baseline it's deviating from, not an absolute threshold applied uniformly across every subscription and team. This is also why a single global alert threshold tends to either miss small teams' real problems entirely or bury large teams in false positives, tiered severity, scaled to each baseline, avoids both failure modes.
The drill-down that separates noise from signal
The fastest way to tell a real anomaly from noise is to ask one question: can you get from "spend went up" to "this specific meter, in this specific subscription, is why" in under a minute? If the answer requires exporting a CSV and pivoting it by hand, most real anomalies will sit uninvestigated simply because the friction is too high. If the drill-down is fast, a spike stops being a mystery and starts being a two-line explanation, a subscription's networking cost jumped because a specific outbound data transfer meter tripled, not just "cost went up in Production-East."
Building a response habit, not just a detection rule
Detection without a response habit doesn't actually save anything. A workable pattern:
- Triage weekly, not daily. Daily review of every fluctuation reintroduces the noise problem from the other direction.
- Resolve or dismiss explicitly. An anomaly that's explained (a planned change) should be marked as such, not left open, or it pollutes the signal for the next review.
- Track resolution time, not just detection count. A team that detects anomalies fast but takes three weeks to act on them isn't much better off than a team with no detection at all.
This is the exact logic behind CloudNomix's anomaly detection view: severity scaled to each subscription's own baseline, not a flat threshold, and a drill-down that goes straight to the meter that actually caused the spike, so a real anomaly gets a same-day answer instead of a CSV export.