Anomaly detection

What counts as an anomaly

Plutus compares each day’s spend against a baseline and flags a day that’s both unusually high and large enough to matter. There’s no machine learning model behind it — every flag is a specific comparison, and the alert text always states which comparison fired.

The detection runs once a day per (cost source, service) group, using the trailing 29 days of cost data:

A group needs at least 3 prior days of history before its latest day can be judged. A connection you just added doesn’t have a baseline yet, so its first few days never trigger a flag.
The baseline is day-of-week aware. If there are at least 4 prior occurrences of the same weekday (4 previous Tuesdays for a Tuesday being evaluated), the baseline is the average of just those days. That keeps a quiet weekend from dragging down the average and making an ordinary Monday look like a spike. Without enough same-weekday history yet, it falls back to a flat average of the prior 7 days.
Two conditions both have to be true. The day has to be at least 50% above its baseline, and the dollar increase has to clear a noise floor (the greater of $10 or 2% of the account’s average daily spend, capped at $500). The floor exists so a swing on a near-zero line — $0.10 going to $0.20 — doesn’t fire just because the percentage looks dramatic.

A flagged day gets a severity of high, medium, or low, based on how far past the noise floor it is — the same severity labels mean the same thing whether the account spends $300 a day or $50,000 a day.

Example: an account’s average Tuesday spend on Amazon EC2 has been $2,100 over the last 4 Tuesdays. Today (a Tuesday) EC2 comes in at $3,400. That’s 62% above baseline and well past the noise floor, so it’s flagged. The alert reads:

Tuesday’s spend of $3,400.00 is 62% above the average Tuesday spend of $2,100.00 over the last 4 weeks.

Where anomalies show up

A flagged day appears two places:

On the Cost Explorer chart, as an annotation on the day it happened — the same overlay used for deploys, incidents, and other timeline events.
On the Alerts page, in a list sorted worst-delta-first, so the account’s biggest mover is always at the top rather than buried under smaller flags.
As a notification, sent to whichever alert channels (Slack, Teams, webhook, email) are subscribed to account-wide alerts — the same delivery path budget alerts and event-overage alerts use.

Per-tag and per-team anomalies

The same detection also runs over any tag you’ve defined rules for (see Virtual tagging & cost allocation) — one series per tag value, so “the platform team’s spend doubled” can be flagged and routed to that team, not just to whoever watches the account-wide feed. This can catch things a service-level check can’t: if a brand-new service appears inside a team’s spend, that service alone has no baseline and won’t flag on its own, but the team’s total jumping is still visible.

Turning on shared-cost redistribution or re-weighting a split rule never creates a false anomaly by itself — the same rule is applied to the current day and its whole baseline, so the ratio between them doesn’t move just because an allocation setting changed.

Because one real incident often shows up in two places — a service spike and the team spike it feeds — a tag-value alert that’s driven by a specific service names that service and, if the service was flagged too, marks it also flagged, so the two don’t read as unrelated notifications about the same money.

Marking an anomaly as expected

Some flagged spend is real and recurring — a monthly batch job, a predictable seasonal spike — and re-flagging it every time it happens is noise. Marking an anomaly as expected creates a suppression that matches on what the anomaly is about, not on the specific day it happened:

Anomaly type	Suppression matches on
Cost source + service	account, cost source, service
Tag value	account, tag key, tag value

This is the important part: suppressing an anomaly doesn’t just dismiss the alert you’re looking at. It stops that same slice of spend from being flagged or notified again in the future, for as long as the suppression exists. A suppressed day still doesn’t get a chart annotation and still doesn’t send a notification — the suppression applies everywhere the anomaly would have shown up, not just the alert inbox.

The suppression is deliberately scoped to the dimensions above and nothing narrower — not the day, not the percentage, not the dollar amount. If it matched on those too, it would only ever apply to the exact anomaly you dismissed and would silently stop working the next time the same spike recurred. It’s also deliberately not scoped any broader — suppressing one service on one cost source doesn’t suppress anything else on that cost source, so a genuinely new problem elsewhere isn’t swallowed along with it.

A suppression can optionally carry an expiration date, but it doesn’t expire by default — an anomaly you’ve marked expected stays suppressed until you remove the suppression yourself. Removing it un-suppresses future occurrences; it doesn’t retroactively restore any alerts that were withheld while it was active.

Each suppression tracks how many anomalies it’s matched, shown as “muted N anomalies” next to the rule, so you can see whether it’s still doing anything.