list_anomalies

com.plutus-cloud/plutus-cost-data · Verify this server

List detected cost anomalies for this account over a trailing lookback window — the real output of Plutus's nightly anomaly detector (severity, baseline vs. current spend, and what drove a tag-level spike), not something recomputed here from raw spend. Prefer this over eyeballing query_costs for "did anything spike" — the detector already accounts for day-of-week baselines and an absolute-dollar noise floor that a naive comparison would miss or over-trigger on. Capped at 200 rows, most recent first; `days` (default 30, max 90) bounds the lookback. `kind` is "service" or "tag". `current_cents`/`baseline_cents`/`delta_cents` are the USD base. `suppressed: true` means a human has marked this exact signature (provider+service, or tag_key+tag_value) as expected — mention it but do not lead with it as a live problem. `driven_by` is null when driver attribution was not measured for this anomaly (a service anomaly, or a grain with no service) and `[]` when it WAS measured and found no dominant driver — those mean different things. `correlated_events` is the service-anomaly counterpart: deploy/incident/release activity that was unusual (above the account's own baseline rate) in the 2-day window ending on the spike day, ranked by share of that excess. Same null-vs-`[]` distinction — null is "not measured" (a tag anomaly, or a row recorded before this shipped), `[]` is "measured and nothing was unusual". It is account-scoped and temporal: it does NOT claim the event caused this particular service's spend to rise, so report it as activity that lines up, never as a cause. `notified: false` means this anomaly was recorded but withheld from alerting because its tag_key was already at the per-run notify cap. Mirrors GET /api/accounts/:accountId/anomalies.