How the detector decides
An anomaly rule doesn't fire on a single loose signal. It requires three gates to hold at once for the same day's spend. First, the value has to beat the trailing baseline's mean plus a set number of standard deviations. This is the z-score gate. The default is 3.0, which is statistically rare for a normal day. Second, it separately has to beat the baseline mean by a minimum percentage (default 50% over). This is a plain-language sanity check that does not rely on the shape of the distribution. Third, it has to clear a minimum absolute dollar floor (default $5), so a service that goes from $2/day to $6/day doesn't page anyone.
The baseline itself is the trailing window of days before the one being evaluated; the evaluated day is never counted in its own baseline. If there are fewer than 2 days of history, the rule does not fire yet. It needs a rough sense of normal before it can call something abnormal.
Raising the z-score or the minimum-percent gate cuts false alarms. It also detects a real problem later, because the value has to climb further before either gate clears. A slow ramp can slip under the gates indefinitely. Each day's increase stays small against the rolling baseline mean, and the baseline mean climbs with it. That is why the third scenario in the simulator above never fires at the default settings. Both gates block it independently. Moving one slider alone never catches it. Lower the z-score to 2.0 and the minimum-percent gate to 10% together, and it is caught on day 24 with no false alarms. Loosen only one of the two, and it stays invisible at every setting. A rule tuned for spikes needs help with a slow leak. Anomaly rules and a budget's burn-down projection work together here.
What you get on day one
Every new org gets an org-wide anomaly rule seeded automatically the first time someone logs in. The rule uses a 14-day lookback, a 3.0 z-score threshold, a 50% minimum over baseline, and a $5 floor. You configure nothing before it is live. The tuning above is for teams that want to scope a rule tighter.
That default rule watches spend. You can add rules that scope to a single provider source (a label like "aws" or "anthropic"), a specific service, or a cost tag. These rules can watch token volume, request count, or tokens per request instead of dollars. That lets a team watch its own slice of the bill without drowning in org-wide noise.
Budgets and the burn-down projection
A budget asks a different question than an anomaly rule. An anomaly rule asks whether today is unusual. A budget asks whether you are still on pace to land under a number you picked. Budgets scope to the org, a provider source, or a tag. They run over either a fixed calendar month or a rolling window (30 days by default). Each one also carries a forward projection: projected total spend and projected percent of budget, based on the pace so far in the period.
Threshold alerts fire at 80% and 100% of budget by default. The warning arrives while there is still room to react.
Watch tokens, not just dollars
Anomaly rules aren't limited to spend. They can also watch token volume, request count, or tokens per request. That last one suits agentic workloads. An agent loop can fan out into far more calls, or far more tokens per call, than intended. This often shows in tokens-per-request before it moves the dollar figure. Pricing tiers and caching can blunt the dollar signal for a while, even after the usage pattern has changed.
The seeded default rule doesn't watch this; it tracks spend. A tokens_per_request rule is one you create and scope to an AI provider source, and it catches the runaway-agent shape this page's first scenario illustrates.
Alerts people don't learn to ignore
Every alert carries a kind (budget or anomaly), a severity (info, warning, critical), and an owner. Its status moves from open to acknowledged to resolved as someone deals with it. Every alert also has a deterministic dedupe key. CostMon derives it from the condition that triggered the alert. The same ongoing anomaly re-evaluates every hour, and it does not spawn a new alert each time. It is the same alert until it is resolved.
The tuning that keeps a rule useful long-term isn't exotic. Give each rule a single clear owner so it doesn't become nobody's job. Favor the absolute floor over the percentage gate for low-spend services, since a 200% jump on a $3/day service is still noise. And if a rule is chatty in its own quiet periods, widen the lookback window or raise the z-score rather than turning it off entirely.
Where it lands
A new alert fans out to every enabled notification channel plus the rule owner's email automatically. There's no separate step to wire a rule to a destination. Channels are email (via SES), Slack, and a generic webhook for anything else in a team's stack. Slack uses an incoming webhook URL. You install no app and authorize no bot. The alert preview in the simulator above shows the exact message, on all three channels.