How to investigate a cloud cost anomaly

Capture the alert and check urgency

Record the affected scope, the evaluated dates, the native currency, and the unexpected amount. Preserve the alert or report reference and note when someone acknowledged it. Ask whether the charge is still growing and whether the workload is business critical. An ongoing incident may need an engineering or security response before a detailed financial investigation is complete.

An anomaly is a deviation from an expected pattern, so the first task is to test that expectation. A planned launch can trigger an alert while serving an approved business purpose. The FinOps Foundation Anomaly Management capability recommends documenting investigation and resolution, including false positives. Assign an accountable investigator even when the initial notification reaches a central finance mailbox.

Validate the data and comparison

Check that the baseline and alert use the same subscription scope, cost metric, and currency. Note filters that exclude charges. Confirm the provider has delivered enough billing data for the evaluated day. Microsoft documents delayed and provisional cost records, and Azure native anomaly evaluation runs after the usage day. Treat an incomplete current day as a provisional observation rather than a full daily total.

Review ordinary workload patterns before interpreting a percentage increase. Weekend schedules, month-end jobs, and new environments can change the relevant baseline. Keep the absolute currency amount beside the percentage so that a small increase from a near-zero starting point does not dominate the response. A budget breach and an anomaly use different expectations; record which signal opened the investigation.

Find the changed charges

Start with the affected subscription and day, then group costs by service or resource group to locate the largest movements. Filter the relevant group and drill into resource and meter where the data supports it. Microsoft recommends this sequence for unexpected charges. Save the filters at each step so that the final explanation reconciles with the original scope.

Look for newly appearing meters and meters whose charges stopped, as well as changes to an existing meter. A resize can replace a meter under the same resource identifier. Retain charges without a usable resource identifier as unresolved billing rows; dropping them can hide part of the increase. If the available product view stops at service-level cost, continue in the provider export instead of inventing resource attribution.

Check the cause with the owning team

The illustrative investigation begins with a EUR 120.00 daily increase. Drilling into one resource reveals a meter replacement, but that observation does not explain why the replacement occurred. Review dated configuration changes and the deployment record with the team responsible for the workload. Compare usage quantities and applicable prices where available to distinguish increased consumption from a rate or SKU change.

An owner tag is a routing clue. Confirm the responsible team, and keep a customer explanation separate from provider evidence. If the team reports a planned performance test, request the approved schedule and end time. If billing detail remains unclear, raise a provider billing question. A lower charge on the next day does not establish that the team performed a corrective action.

Scroll the table sideways on smaller screens. Keyboard: focus the table and use the arrow keys.

Choose a response through the normal change process

For expected spend, document the business explanation and decide whether the forecast or alert baseline needs an update. For unexpected usage, the engineering owner should propose a bounded change with dependency checks and a rollback plan. A cost alert alone does not authorize a shutdown. Route suspected unauthorized activity through the security process while preserving relevant evidence.

Record the decision and the approving authority before changing resources. Assign a follow-up time appropriate to the continuing cost exposure, then confirm the resulting usage and charges once data is available. Costframe does not automatically remediate customer cloud resources. Product findings can inform review, but implementation happens through your authorized cloud change process. Keep requested work separate from confirmed completion in the investigation record.

Close with an explanation and a follow-up measurement

Close the investigation with the affected interval, explained charge movement, evidence references, owner, and remaining uncertainty. Outcomes can include expected launch cost, billing adjustment under review, corrected configuration, or unresolved ownership. A reasoned expected-cost outcome is useful even when there is no optimization action. Improve routing or data coverage when missing metadata delayed the investigation.

Keep projected cost avoidance separate from an observed financial outcome. Estimating what a runaway workload would have spent if left running requires an explicit duration assumption. A before-and-after service difference can remain MEASURED_UNATTRIBUTED in Costframe and cannot be called verified savings. Use the savings-verification guide for attribution checks, then include repeated incidents and overdue investigations in the monthly cost review without duplicating their financial amounts.

Related guidance