How to review an Azure cost anomaly
A cost anomaly is an unexpected change relative to an appropriate historical and business baseline. It can be a harmful runaway event, an intended deployment, delayed billing, a credit change, or normal seasonality; anomaly does not mean waste.
Explain the largest meter contribution firstWho reviews this signal?
- Accountable owner
- FinOps + service owner
- Review cadence
- Daily
Check observation dates and read-only scope. Your team approves and implements changes outside Costframe.
How this finding happens
- →Runaway telemetry, data processing, scaling, or automation increases usage.
- →A legitimate release, migration, or business event changes demand.
- →Late-arriving cost, refunds, credits, currency, or allocation changes distort the comparison.
Collected evidence and verification limits
Checked when available
- ✓ActualCost time series by scope, service, meter, resource, and charge type
- ✓Baseline window, expected range, deviation, and contribution breakdown
- ✓Deployment, incident, scaling, and business-event context where integrated
- ✓Data freshness and known provider billing delay
Not always verifiable
- —Cost data arrives after usage and may be revised.
- —A statistical deviation cannot infer business intent.
- —New resources and sparse series need different baselines from stable services.
Missing or stale evidence is a limitation, not a passed check.
Why this finding might be wrong
These conditions lower confidence or require manual owner review before action.
- Planned launch, migration, load test, or seasonal event
- Delayed or corrected billing record
- Credit, refund, reservation, or allocation change
- Expected growth in a new workload with little history
Plan the change and recovery path.
- Confirm freshness and rule out billing corrections before escalating.
- Decompose the change by service, meter, resource, region, and charge type.
- Correlate with deployments, incidents, scaling, and business events.
- Route to the owner with severity based on burn rate, confidence, and operational context.
Rollback / recovery
Rollback is workload-specific: stop the runaway job, restore scaling/configuration, or revert the deployment through the normal incident process. Costframe does not mutate the environment.
How savings are calculated
An anomaly value is spend variance or exposure, not automatically savings. Savings are counted only after a corrective action and suitable billing verification.
Do not quote a quantified saving when the billing scope, pricing basis or required workload evidence is incomplete or stale. Treat a modeled amount as estimated until suitable billed outcomes support it.
Check the billed outcome
The cost rate returns to an explained range and the incident/action trail accounts for the variance.
Explain the largest meter contribution first
Check whether the affected period is complete, then split the variance by meter, resource and charge type. Match the largest contribution to a deployment, job or billing correction with its owner. Escalate an unexplained active burn rate through the incident process, not as a confirmed saving.
Follow the anomaly investigationIf the owner cannot resolve a dependency or recovery requirement, keep the candidate in review rather than treating it as approved.