Azure Cost Management alerts are enabled by default for most subscriptions. Ask any engineering team whether they have cost alerts configured, and most will say yes. Ask them when they last acted on one, and the room goes quiet. Default alerts are noise generators. They alert the wrong people, at the wrong thresholds, with no context about whether the spike is expected or unexpected. This guide is about the configuration that produces signal.
Why Default Alerts Fail
The failure is not a technical one — it is a design one. Default budget alerts fire at 80% and 100% of a budget. That sounds reasonable until you look at how budgets are typically set: previous year’s actual spend, plus a buffer negotiated in an annual planning cycle, rounded up to a number that made finance comfortable. That number bears little relationship to what a workload should cost. It is not a meaningful threshold — it is a historical artefact with a margin applied.
The alert recipient problem compounds this. Subscription owners receive alerts by default. In most organisations, the subscription owner is either a service account, a distribution list nobody monitors, or a senior engineer who left eight months ago. Even when the alert reaches a real person, it arrives without context: “you have spent £X of your £Y budget.” Nothing in that notification tells the recipient whether the spend is expected, what resource is driving it, or what they are supposed to do about it.
The result is alert fatigue at organisational scale. Teams learn — rationally — to treat cost notifications as noise. The genuine spike, when it comes, is lost in a stream of notifications that have never required action. The fix is not more alerts. It is better-targeted alerts with defined ownership and enough context to make them actionable.
Configuring Budget Alerts Properly
The most important decision in budget alert configuration is scope. Subscription-level alerts are almost always too broad to be actionable — a spike in one workload is buried in the aggregate of everything else running in the subscription. Scope your alerts at the resource group or workload level, where the recipient actually has context about what should be running and why.
Threshold selection should be based on the expected spend variance of the workload, not an arbitrary percentage. If a workload is predictable — a fixed number of VMs, steady traffic, no significant batch jobs — then a 115% threshold is meaningful: it represents genuine overspend that warrants investigation. If the workload is inherently variable, a 115% threshold will fire constantly on normal business cycles. For variable workloads, 130–150% is a more useful signal.
Add forecast-based alerts alongside actual-spend alerts. A forecast alert fires when Azure’s ML model predicts you will exceed budget before the end of the billing period — giving you time to act rather than merely observe. Actual-spend alerts at 100% tell you the damage is done. Forecast alerts at 90% give you a window to intervene.
Alert recipients should be the workload owner and the architect or engineer responsible for the service. Not subscription admins. Not the finance team as the first recipient. Not a shared mailbox that seventeen people have access to and nobody owns. Routing alerts to the person who can explain and act on the spend is the single most effective change most teams can make.
[DAN: Add your preferred alert threshold configuration for a standard production workload — actual percentages, forecast vs actual, and who you route alerts to in a typical engagement. Specifics here are what practitioners find valuable.]
Anomaly Detection — Signal vs Noise
Azure Cost Management anomaly detection is a different tool from budget alerts and is frequently misunderstood or conflated with them. Budget alerts are threshold-based: spend crosses a line, alert fires. Anomaly detection uses a machine learning model to identify spend patterns that deviate from a learned baseline — it responds to relative change, not absolute levels.
This distinction matters in practice. A 300% spike on a workload that typically costs £10/day will be detected. A 5% increase on a workload that typically costs £10,000/day will not — and in most cases, should not be, because 5% is within normal variance for high-spend workloads. Anomaly detection is calibrated to the signal that matters at each scale, which makes it genuinely useful rather than just another threshold mechanism.
The main failure mode of anomaly detection is false positives from expected events. A major load test, an end-of-month batch job, a deliberate scaling event for a product launch — these all look like anomalies to a model trained on normal patterns. The fix is simple but requires discipline: tag expected high-spend events in advance. A cost management note, a shared engineering log, a Confluence entry — anything that creates a record you can reference when the anomaly alert arrives. Without this, the on-call engineer receives an anomaly alert during a planned event and has to investigate something that required no investigation.
Where anomaly detection earns its keep is in catching patterns no threshold would have been set for: the development VM left running over a bank holiday weekend, the autoscaling group that hit its maximum instance count and nobody noticed, the trial API service that was evaluated and forgotten. These are all genuine anomalies against a stable baseline — low-probability events that would otherwise go undetected until the next monthly review.
Where it underperforms is on workloads with inherently variable spend patterns. Event-driven architectures, seasonal commerce platforms, and anything that processes batch work on an irregular schedule will generate noise from anomaly detection because the model cannot establish a stable baseline. For these workloads, set explicit budget alerts with appropriately wide thresholds and rely on scheduled cost reviews rather than trying to make anomaly detection work against a pattern it cannot learn.
Connecting Alerts to Action
An alert that fires and produces no defined action is worse than no alert. It is training data for your organisation, and the lesson it teaches is that cost alerts do not require a response. That learned behaviour is extremely difficult to reverse once it is established.
For every alert configuration, define three things before you enable it: who receives it, what they are expected to do when it fires, and what the escalation path is if they cannot resolve it within 24 hours. This does not need to be complex. A shared runbook entry or a note in a team wiki is sufficient — the point is that the expectation is explicit and not left to the recipient to determine under pressure.
For budget alerts, the workload owner investigates and makes one of two determinations: the spend is expected (the alert was triggered by a planned event, growth, or a legitimate cost increase) or it is unexpected (something is running that should not be, or a resource is consuming more than planned). Expected spend requires documentation — the budget needs to be revised if it no longer reflects reality. Unexpected spend requires a remediation action with a defined timeline.
For anomaly alerts, the appropriate response is triage on the same business day. Is this a genuine anomaly or an expected event that was not logged in advance? If it is genuine, treat it with the urgency of an infrastructure incident — because cost spikes of the magnitude that trigger anomaly detection are often symptoms of infrastructure problems rather than just billing issues. Runaway scaling loops, misconfigured retry logic causing excessive API calls, and orphaned resources from failed deployments all present as cost anomalies before they are identified as engineering problems.
[DAN: Add how you’ve integrated cost alerts into engineering workflows in practice — whether you routed to Slack/Teams, tied to incident management, or used a different mechanism. The integration pattern is often more useful than the Azure configuration itself.]
The Monitoring Hierarchy
No single alerting mechanism gives complete cost visibility. The approach that works treats different alert types as layers in a hierarchy, each catching what the others miss.
Budget alerts at the workload level catch predictable overspend — the workload that has grown beyond its budget, the resource configuration that was never revisited after a cost-saving initiative elsewhere increased load on this component. These alerts fire before the overspend hits the subscription aggregate, where it becomes much harder to attribute and act on.
Anomaly detection at the subscription level catches unexpected patterns across all workloads — the events that no budget threshold would have caught because nobody anticipated them. This layer is the broad net.
A weekly cost analysis review — an architect or engineer with context looking at the trend line for each workload, asking whether it is expected and whether it is justified — catches what automation misses. Gradual cost creep that stays below alert thresholds. Workloads whose spend is technically within budget but whose budget was set when the workload had a quarter of its current data volume. The review is the layer where human context and automation output meet.
All three layers together give reliable cost visibility. Any one in isolation leaves significant gaps.
Cost alerts are not a monitoring solution. They are the safety net. The real monitoring is the regular cost review where an architect with context looks at the trend, asks whether it is expected, and makes a decision. Alerts catch what falls through the review. Build both.
