← All posts · 2026-07-24

Your Azure bill jumped. Here is how to find out why

The Azure bill arrives, it is up 40 percent, and the person who notices is in finance, not engineering. Here is how to find the cause quickly, and how to stop learning about spikes from the invoice.

Start with Cost Analysis, daily granularity

In Cost Management, switch the view to daily costs and look at the shape. A one-day step change points at a deployment or a configuration change on that date. A gradual ramp points at growth: data, traffic, or retention quietly accumulating.

Group by service, then resource group

Group the daily view by service name to find what category jumped: compute, SQL, storage, bandwidth. Then group by resource group to find whose it is. Two group-bys usually narrow a mystery spike to one team's one workload in a few minutes.

The usual suspects

• A VM size change or a new environment left running after a test.
• SQL or Cosmos scaled up during an incident and never scaled back.
• A runaway query or job burning compute on a schedule.
• Log ingestion or storage retention growing without a cap.
• Egress from a new integration moving data out of region.

Match the date to a change

Once you have the day and the resource group, check deployments and configuration changes on that date. The cause is almost always a human decision with a timestamp, not a billing mystery.

Make next month boring

Set a budget as your hard ceiling, then add anomaly detection against a rolling baseline so a service that jumps 3x gets flagged the next day, with the service and resource group named. The forty-percent surprise becomes a Tuesday email about one workload, handled while it is one day old.