list_anomalies
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.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Trailing lookback window in days (default: 30) |