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 configurable number of standard deviations (a z-score gate, default 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) as a plain-language sanity check that doesn't 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. And if there are fewer than 2 days of history to build that baseline from, the rule simply doesn't fire yet, since it needs at least a rough sense of normal before it can call something abnormal.
The tension worth understanding: raising the z-score or the minimum-percent gate cuts false alarms but detects a real problem later, since the value has to climb further before either gate clears. A ramp gradual enough that each day's increase stays small relative to the rolling baseline mean can also slip under the gates indefinitely, because the baseline mean climbs right along with it. That's why the third scenario in the simulator above never fires at the default settings. Both gates are blocking it independently there, which is why moving any one slider on its own never catches it: lower the z-score to 2.0 and the minimum-percent gate to 10% together and it's caught on day 24 with no false alarms, but loosen only one of the two and it stays invisible at every setting. A slow leak is the case where a rule tuned for spikes needs help, which is why anomaly rules and a budget's burn-down projection work together rather than as substitutes for each other.
What you get on day one
Every new org gets an org-wide anomaly rule seeded automatically the first time someone logs in: 14-day lookback, 3.0 z-score threshold, 50% minimum over baseline, $5 floor. There's nothing to configure before it's live; the tuning above exists for teams that want to scope a rule tighter, not because the default needs babysitting.
That default rule watches spend. From there, additional rules can scope to a single provider source (a label like "aws" or "anthropic"), a specific service, or a cost tag, and they 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 is a different question than an anomaly rule: not "is today weird" but "are we still on pace to land under a number we picked." Budgets scope to the org, a provider source, or a tag, run over either a fixed calendar month or a rolling window (30 days by default), and carry 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, so the warning arrives while there's still room to react, not the day the ceiling is already crossed.
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 is the standout for agentic workloads: an agent loop that fans out into far more calls, or far more tokens per call, than intended surfaces in tokens-per-request before it necessarily moves the dollar figure, because pricing tiers and caching can blunt the dollar signal for a while even as the underlying usage pattern has already 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), an owner, and a status that moves from open to acknowledged to resolved as someone deals with it. Every alert also has a deterministic dedupe key derived from the condition that triggered it, so the same ongoing anomaly re-evaluating every hour doesn't spawn a new alert each time. It's the same alert until it's 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 (a 200% jump on a $3/day service is still noise), and widen the lookback window or raise the z-score if a rule is chatty in its own quiet periods 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 (an incoming webhook URL, no app to install or bot to authorize), and a generic webhook for anything else in a team's stack.