Responding to an Azure cost anomaly alert

Cost anomaly alerts fire when daily spend for a service deviates more than 3σ from its baseline. Most anomalies are legitimate (a new workload, a planned scale-up) — the job is to confirm ownership quickly, not to shut things down reflexively.

Triage in order

• Open the alert’s resource breakdown — which specific resources drive the delta?
• Check the activity log for those resources over the anomaly window: who deployed or resized what?
• Match against the change calendar — planned work should reference a change record
• Contact the owner from the resource tags before taking any action

Common causes ranked

• Autoscale responding to real load (verify with the app team, usually fine)
• Non-prod resources left running after testing (stop them, add an auto-shutdown policy)
• A deleted resource’s diagnostic setting still streaming to a paid sink
• Data egress from a misconfigured replication or backup job
• Cryptomining on a compromised VM — if CPU is pinned and the owner knows nothing, treat as a security incident immediately

Useful queries

# Yesterday's cost by resource for a subscription, largest firstaz costmanagement query \  --type ActualCost \  --scope "subscriptions/<sub-id>" \  --timeframe Custom \  --time-period from="2026-07-28T00:00:00Z" to="2026-07-29T00:00:00Z" \  --dataset-aggregation '{"totalCost":{"name":"Cost","function":"Sum"}}' \  --dataset-grouping name="ResourceId" type="Dimension" \  --query "properties.rows[?[0] > \`50\`]" -o table