Cost Anomaly Detection: Spot Spend That Grew Without Work

Last verified on Nov 8, 2026.

A cost anomaly is spend that rose without a matching rise in work. Traffic is flat, yet the data transfer line doubled. Signups are steady, yet token usage tripled. A bill that grows with your business is growth. A bill that grows without it is a defect, and defects are cheaper to fix the day they start.

This guide covers detecting them from billing data, usage metrics and logs, whatever the provider.

Where anomalies come from

• A deploy that adds a noisy log line or a verbose debug mode.
• A retry loop or a runaway job that repeats expensive calls.
• A new feature that fans out to more services or models per request.
• A resource left running after a test, or created in the wrong region.
• Data that moves across regions or out to the internet when it used to stay put.
• High-cardinality metrics or labels that multiply what you store.

What the evidence looks like

You need two series side by side: cost and the work that should drive it. Example daily rows after joining billing with request counts:

date        service        cost_usd   requests    cost_per_1k_requests
2026-11-05  data-transfer     212.40   4,810,000   0.044
2026-11-06  data-transfer     219.10   4,950,000   0.044
2026-11-07  data-transfer     441.70   4,880,000   0.091

Requests held steady and cost per thousand requests doubled. That ratio is the anomaly, and the absolute dollar change is secondary.

Detect it step by step

1. Get cost data at daily or finer grain, tagged by service, environment and team. AWS documents that cost allocation tags must be activated before they appear in Cost Explorer or on a cost allocation report, so activate them early.
2. Join cost to a driver: requests, jobs, active users, tokens or GB processed. Compute unit cost.
3. Compare each day with the same weekday in recent weeks, not with yesterday:

-- Example: services whose daily cost is well above the same weekday's recent median
WITH daily AS (
  SELECT service, date_trunc('day', usage_start) AS day, sum(cost) AS cost
  FROM billing_export
  GROUP BY 1, 2
), baseline AS (
  SELECT service, percentile_cont(0.5) WITHIN GROUP (ORDER BY cost) AS median_cost
  FROM daily
  WHERE day >= current_date - 36 AND day < current_date - 1
    AND extract(dow FROM day) = extract(dow FROM current_date - 1)
  GROUP BY service
)
SELECT d.service, d.cost, b.median_cost, d.cost / b.median_cost AS ratio
FROM daily d JOIN baseline b USING (service)
WHERE d.day = current_date - 1
  AND d.cost > 1.5 * b.median_cost AND d.cost - b.median_cost > 50
ORDER BY d.cost - b.median_cost DESC;

4. Break an anomaly down by dimension to find the cause. AWS Cost Anomaly Detection ranks root causes by dollar impact across four dimensions: service, account, Region and usage type. Do the same with your own tags.
5. Watch leading indicators that move before the invoice: log bytes ingested, request counts to paid APIs, tokens consumed.

Thresholds and pitfalls

Use a relative threshold and an absolute floor together. A 200 percent rise on a service that costs 3 dollars a day is not worth a page. A 20 percent rise on a service that costs 5,000 dollars a day is.

Billing data lags. AWS says Cost Anomaly Detection runs approximately three times a day, uses Cost Explorer data that can be up to 24 hours late, needs 24 hours to begin detecting on a new monitor and needs 10 days of history for a new service subscription. Expect delay from any billing-based check, and use usage metrics for faster signals.

Other false-positive sources:

• Month-start charges, commitments and credit expiry reshape the daily line without any change in usage.
• One-time purchases such as support plans or reserved capacity look like spikes.
• Weekly and monthly seasonality matter. AWS notes its machine learning methods evaluate weekly or monthly seasonality and natural growth to limit false positives, and your own check needs the same awareness.
• A sale or launch raises cost legitimately, so annotate known events.

What to do when it fires

Identify the resource or code path, then decide whether the spend buys value. Stop the runaway first: disable the job, remove the log line, cap the retries. Then add a guard that would have caught it: a budget alert, a per-feature limit or a unit cost alert. Record the cause so the next review has context.

Read the specific guides for cloud spend anomalies, LLM spend spikes and cardinality jumps. The efficiency issues overview ties cost together with telemetry gaps. For AWS accounts see the AWS integration, and send usage metrics through Prometheus or OpenTelemetry for faster signals than billing gives you.