Cost

Investigate an Azure cost anomaly

An Azure cost anomaly surfaced in Cost analysis isn't always a problem, but it always means the bill changed. Triage, attribute, decide.

15 min·10 sections·AZURE

Last reviewed 19 June 2026

Azure cost anomalies: the basics

What does it mean for Azure spend to be "anomalous"?

A cost anomaly is a day of spend that lands far enough outside the expected range for a subscription that a model trained on recent daily usage flags it as unlikely to be normal variation. Daily Azure spend has a natural rhythm: batch jobs run overnight, traffic dips at the weekend, a monthly reservation purchase lands on the same date. Microsoft Cost Management learns that rhythm and surfaces the days that break it.

Azure Cost Management runs anomaly detection automatically for every subscription. It applies a model to your daily usage, and when a day's spend sits materially above or below the prediction it surfaces the result as an insight inside Cost analysis. You do not configure or pay for the detection itself: it is a free Cost Management feature, and the insight names the day, the magnitude of the change and the direction. The detector's output is not "something is wrong", it is "this looks unusual, here is what changed".

A real example: total spend on a subscription jumped from an expected 188 of currency per day to an actual 1,366 per day, a roughly 7x change, driven by a single resource group. The detector had been watching that subscription for weeks and was confident the previous days fit the pattern. That is an anomaly worth a human looking at: not necessarily an emergency, but the bill changed and someone needs to know why.

In this lesson you will learn how Azure cost anomaly detection actually works, the triage decision tree for any spike (usage change vs. rate change), how to attribute a 7x anomaly back to a specific resource group and a specific team in under thirty minutes, and how to decide whether the new cost should be accepted (budget up) or fixed (root-cause down). You will see the Cost analysis attribution workflow, how scheduled anomaly alerts and Budgets alerts complement each other, and the one-line post-mortem that turns a one-off spike into team-wide muscle memory.

Fun fact

The most expensive bug is the one nobody owns

A well-cited industry estimate is that 30%+ of cloud spend is wasted, and a meaningful chunk of that waste lives in anomalies that nobody investigated because they fell into the cracks between teams. The detection is the cheap part: Azure Cost Management runs anomaly detection on every subscription automatically and for free. A 7x spike on a shared subscription is everyone's problem and therefore nobody's. The first team to claim an anomaly tends to fix it; the ones that bounce between Teams channels for two weeks become the line items finance asks about in the next quarterly review.

Triaging an Azure cost anomaly in action

Marco runs FinOps at a healthcare SaaS. On a Friday morning he opens Cost analysis for the production subscription and the Insights surface a detected anomaly: daily spend jumped from an expected 188 to an actual 1,366 on 2026-02-26, a roughly 7x change. Cost Management flags it automatically; Marco had also set up a scheduled anomaly alert, so the same insight arrived by email overnight. He did not have to build the detector, it ships with the subscription.

Before pinging anyone, Marco runs the triage decision tree. Cost = usage x rate. So the spike is either a usage change (a new resource, more requests, more data) or a rate change (a reservation that lapsed, a region with different pricing, a SKU change). He starts with usage because that is the more common cause and the easier one to verify.

In Cost analysis he changes the Group by from None to Resource group for that subscription and date range, then narrows to the anomalous day. The 80/20 of any anomaly is usually one resource group doing 80% of the damage. He then groups by Service name and by Tag to pin the exact resource and the owning team, the whole attribution workflow living inside the portal because the detection itself is portal-driven.

Anomaly detection is surfaced in the Cost analysis portal, so the attribution here is portal-driven: group by resource group, then service, then tag. The optional commands below set up the email alerting that complements it. First, create a scheduled anomaly alert so the next anomaly emails you the day it is detected.

$ # Scheduled anomaly alerts are created in Cost Management > Cost alerts > Anomaly alerts (portal). # They run the same automatic detection on the subscription's daily usage and email # the named recipients when an anomaly is found. # # Portal flow: # Cost Management > Cost alerts > + Add > Anomaly alert # Scope: the subscription | Recipients: [email protected] # Frequency: Daily (the detection model runs on daily usage)

Anomaly alert 'finops-daily-anomalies' created.

Scope: /subscriptions/00000000-0000-0000-0000-000000000000

Recipients: [email protected] | Frequency: Daily

# Detection itself is free and always on; the alert just emails the result.

Detection runs automatically and free on every subscription; the scheduled anomaly alert is the optional email layer on top, configured in the Cost Management portal.

Budget alerts are a separate, complementary mechanism: threshold-based rather than model-based. Create the budget with the az CLI, then add its alert thresholds and recipients on the budget in the portal, so finance is warned when month-to-date spend crosses a fixed percentage of plan, regardless of whether the model calls it anomalous.

$ az consumption budget create \ --budget-name finops-prod-monthly \ --amount 25000 \ --category cost \ --time-grain monthly \ --start-date 2026-02-01 \ --end-date 2027-02-01

{

"name": "finops-prod-monthly",

"amount": 25000.0,

"timeGrain": "Monthly",

"notifications": null

}

# Budget created. Add its alert thresholds and recipients in the portal: Cost Management > Budgets.

# A budget alert is a tripwire on a fixed number; the anomaly model catches the shape of the change.

Budgets live under Cost Management > Budgets: create the budget with the CLI, then add its alert thresholds and recipients there. They complement, rather than replace, the model-based anomaly detection, covering both a sudden anomalous shape and a slow creep towards the plan limit.

How Azure cost anomaly detection actually worksdeep dive

Under the hood, Azure Cost Management applies a model to the subscription's daily usage. It learns the recent pattern of spend (weeknight batch peaks, weekend dips, end-of-month jobs), computes an expected value for each new day, and flags the day when the actual lands materially outside that expectation. The result is surfaced as an insight in Cost analysis, naming the day, the magnitude and the direction of the change. Detection runs at subscription scope, automatically, and is a free Cost Management feature: there is no model to train or service to pay for.

Persistence is the strongest signal. A single day at 7x could be a one-off (a one-shot batch job, a botched test). Several consecutive days at 7x means the cost base has moved and the change is real. When you investigate, sort your attention by how many days the elevated spend has persisted, not by the headline magnitude of any single day. A one-day spike that self-corrects is noise; a sustained shift is a forecast event.

It is worth contrasting this with AWS. AWS Cost Anomaly Detection asks you to create monitors across dimensions (services, linked accounts, cost categories, tags), each with its own alert subscription and threshold. Azure's model is more turnkey: detection is on by default at subscription scope with no monitors to configure, surfaced in Cost analysis Insights, with optional scheduled anomaly alerts for email. The detection concept is the same on both clouds (learn a daily baseline, flag the days that break it); the difference is that Azure does the wiring for you, so the work shifts almost entirely to attribution and response.

# Azure cost anomaly detection is surfaced in the Cost analysis portal Insights,
# not via a dedicated anomaly CLI, so attribution is done in the portal:
#
#   Cost Management > Cost analysis
#   Scope: the subscription
#   Group by: Resource group   -> find the 80/20 resource group
#   Group by: Service name     -> find the dominant service
#   Group by: Tag              -> find the owning team
#   Date: narrow to the anomalous day
#
# To export the underlying daily usage for offline attribution, pull cost details
# with the az CLI (the resource group is embedded in each instanceId / resource ID):
az consumption usage list \
  --start-date 2026-02-26 --end-date 2026-02-26 \
  --query "[?contains(instanceName, 'gpu')].[instanceName, pretaxCost, instanceId]" \
  --output table

What is the impact of unattributed Azure cost anomalies?

The direct impact is the bill. A persistent 7x spike on a subscription that was running 188 per day costs an extra ~35k a month if nobody catches it, and "nobody catches it" is the default outcome when an anomaly bounces between Teams channels for a week. The detector did its job, and it did it for free; the cost is the gap between detection and ownership.

The second-order impact is forecast pollution. Budgets, reservation recommendations, and capacity plans all train on recent spend. An unflagged anomaly that persists becomes the new baseline; six weeks later you are sizing your reservation commitment on numbers that include 35k a month of accidental GPU spend. The model cannot tell the difference between intentional growth and a forgotten test rig.

The third-order impact is trust. Finance loses confidence in cloud spend forecasts when anomalies do not get explained; engineering loses confidence in the alert channel when too many anomalies fire without follow-up. Both problems compound: finance starts demanding manual approval for any spend increase, engineering starts muting the channel and the scheduled anomaly alerts that came for free.

The good news: anomalies that are attributed within 24 hours rarely cost more than a few thousand in waste. Speed of triage is the dominant variable. Because the detection is already free and automatic in Cost analysis, the only thing standing between a 35k surprise and a 2k one-off is whether a documented owner per subscription claims the anomaly fast.

How do you triage and act on an Azure cost anomaly?

Anomaly response is a four-step loop. The detection is free and automatic, so the work is all in the response. Skipping any step turns a one-day spike into a six-week mystery.

1. Attribute: find the resource and the owner

In Cost analysis, group the anomalous day by Resource group to find the 80/20, then by Service name to find the dominant service, then by Tag to find the owning team. If your resources carry an owner or cost-centre tag, the whole exercise is 15 minutes. The detection already pointed you at the day; this step turns the day into a name.

2. Diagnose: usage change or rate change?

Cost = usage x rate. If usage rose, check the activity log for new resource deployments and Azure Monitor for traffic, queue or processing increases on existing resources. If usage is flat, check rate: a reservation or savings plan that lapsed, a workload that moved to a more expensive region, a switch from spot to standard virtual machines. Data-transfer spikes (especially cross-region and cross-zone bandwidth) are the most-missed category, so always look at the networking services in the Service name grouping.

3. Decide: intentional or accidental?

Once you know what changed and who owns it, ask the owner one question: was this intentional? If yes (feature launch, planned capacity, marketing event) update the budget and forecast: that is now the new normal and the model will relearn it over the coming days. If no (forgotten test rig, autoscale bug, runaway loop) treat it as a real incident: fix the root cause and verify the next day's spend returns to the expected band in Cost analysis.

4. Layer the alerts and write the one-liner

Make sure a scheduled anomaly alert emails the model's detections, and add a Budgets alert at a sensible percentage of plan as a separate threshold-based backstop, the two cover different failure modes. Then every anomaly should produce a single-sentence note: "X caused Y, fixed by Z, prevented by W." Build the team library so the second occurrence of a pattern (GPU virtual machines left running over a weekend, a reservation that lapsed, log retention misconfigured) is a 30-second triage, not a re-investigation.

# The model-based detection is on by default and free. Add the two alerting
# layers that complement it.
#
# 1) Scheduled anomaly alert (model-based, emailed) is created in the portal:
#    Cost Management > Cost alerts > + Add > Anomaly alert
#    Scope the subscription, set Daily frequency, add recipients.
#
# 2) Budget alert (threshold-based), a separate complementary tripwire. Create the
#    budget with the CLI, then add its alert rules in the portal (Cost Management > Budgets):
az consumption budget create \
  --budget-name finops-prod-monthly \
  --amount 25000 \
  --category cost \
  --time-grain monthly \
  --start-date 2026-02-01 \
  --end-date 2027-02-01
#
# Then in the portal (Cost Management > Budgets) open finops-prod-monthly and add alert
# conditions: actual >= 80% and forecast >= 100%, with finance as the recipients.

Quick quiz

Question 1 of 5

Cost analysis Insights surfaces an anomaly: daily spend on a subscription jumped from an expected 188 to an actual 1,366, a roughly 7x change, detected on a single day. What is the right next step?

Keep learning

Dig deeper into Azure cost anomaly detection, the attribution workflow, and how Budgets complement it.

You have completed Investigate an Azure cost anomaly. You now know that Azure Cost Management detects anomalies automatically and for free at subscription scope, surfacing them in Cost analysis Insights, with scheduled anomaly alerts for email and Budgets as a separate threshold-based backstop. You know the usage-vs-rate triage decision tree, how to attribute a 7x spike to a resource group and an owner in under thirty minutes by grouping in Cost analysis, and how to close every anomaly with a one-line post-mortem. The next time the Insights flag 1,177 of variance, you will have a four-step loop (attribute, diagnose, decide, alert-and-document) ready to run.

Back to the library

Azure cost anomalies: what finance needs to know

A statistical signal that the bill changed, and a prompt to find out whether it should have

An Azure cost anomaly is a data point: the actual spend on a subscription on a given day came in materially outside the range the model predicted from recent daily history. Cost Management learned the normal rhythm of that spend and flagged a value that breaks the pattern. It is a signal that something changed, not a diagnosis of what changed or whether it matters, and crucially the detection costs nothing because it is built into Cost analysis.

For finance, the number that counts is the variance in money: how much did actual exceed expected, and has it persisted? A single-day variance of 1,177 on a 188-per-day subscription is notable but might be a one-shot batch run. Sixteen consecutive days of the same variance is 18,800 of unplanned run-rate (potentially 226k annualised) that belongs in the forecast revision and the budget conversation. Persistence is the variable to watch; it converts a spike into a rate.

The central question for every anomaly is ownership: which team ran the cost up, was it intentional, and does the forecast need to move? A usage spike caused by a feature launch is expected spend that just was not communicated to finance in time: the right response is to update the budget, not to reverse it. A forgotten test rig is waste that should be stopped. The detector cannot tell the difference; only attribution to an owner and a conversation with that team can.

This lesson is for the finance partner who wants to understand what an Azure cost anomaly insight actually represents, how the numbers (expected cost, actual cost, variance, how many days it has persisted) translate to budget exposure, and how to distinguish planned spend that was not communicated from genuine waste. No command line required. The focus is the attribution workflow in Cost analysis, the decision to accept or fix, and the forecast and budget adjustments that close the loop.

Fun fact

The most expensive bug is the one nobody owns

How a finance partner moves through an anomaly insight

Dana is the finance partner for the platform org. When the 1,177 spike lands in her inbox from the scheduled anomaly alert she does not start with the portal filters, she starts with the numbers. Expected 188 per day. Actual 1,366 per day. Detected on one day so far. That last point matters: a single-day spike at 7x could be a one-shot batch run that self-corrects; if it persists for 5 or 10 days she is looking at 6k to 12k of unplanned month-to-date variance and a potential 35k run-rate change.

Her first question is whether there is a named owner on the subscription. She opens Cost analysis, groups the anomalous day by Tag, and sees the spend concentrated under a resource group tagged to the ML Research team. That gives her someone to call before escalating anything. She drops a one-line Teams message: "1,177 spike on the production subscription yesterday, all in the ML Research resource group. Intentional? If so I need to update the forecast."

K. Tanaka replies within the hour: two GPU virtual machines launched for a short training run, expected to deallocate by Sunday. Dana logs the conversation, notes the expected shutdown, and sets a calendar check for Monday to confirm the resources stopped and the anomaly closed. If they are still running on Monday, that becomes a 35k-per-month forecast revision conversation, and a Budgets amendment request if the run goes longer than the sprint.

The financial exposure of an unattributed anomaly

The direct cost is arithmetic. A 188-per-day subscription at 7x produces an extra 1,177 per day of unplanned spend. One day is a rounding error in most budgets. But if the anomaly persists for 30 days, which is the median outcome when nobody claims ownership, that is 35,310 of unbudgeted run-rate, roughly 424k annualised. Cost Management flagged it on day one for free; every subsequent day of delay is a finance problem, not a detection problem.

The second financial impact is forecast contamination. Reservation coverage recommendations, savings-plan sizing, and next-quarter budget models all ingest recent spend data. An unattributed anomaly that persists for four to six weeks silently inflates the baseline those models train on. You end up over-committing to a reservation because the model believed 1,366 per day was the new normal for that subscription, and unwinding an over-commit costs money too.

The chargeback and audit-trail impact runs parallel. If your chargeback model allocates spend to the team that owns the resource group, an unattributed spike shows up as an unexplained cost in that team's report. Finance gets questions it cannot answer, teams dispute charges they did not authorise, and the credibility of the cost allocation model erodes. A one-line attribution note per anomaly ("ML Research team, training run, intentional, expected to close Sunday") is all the audit trail you need.

The controllable variable is speed of closure. Anomalies resolved within 24 hours rarely accumulate more than 1 to 2k in waste; anomalies that drift for a week routinely reach 8 to 12k before someone escalates. Pair the free anomaly detection with a Budgets alert as a backstop and an SLA on response time (e.g., any anomaly over 500 variance gets an owner claim within 4 business hours) and you have the single highest-ROI process in anomaly management.

The finance partner's triage loop for an Azure cost anomaly

Finance does not run the portal filters directly, but it owns the SLA, the attribution record, and the budget decision that closes the anomaly. The detection is free; finance owns the response. Four steps, used every time.

1. Convert variance to run-rate exposure

The first thing to compute is days-persisted x daily variance. One day of 1,177 is noise; ten days of 1,177 is 11,770 of month-to-date overrun and a ~429k annualised run-rate change that belongs in the next forecast revision. Sorting the anomaly inbox by (days x variance) rather than headline magnitude alone surfaces the ones that matter financially.

2. Check ownership before escalating

Ask the platform team to group the anomalous day in Cost analysis by Tag, or use your cloud governance model, to identify the owning team before pinging anyone. A cold message to the wrong team creates noise; a message to the right owner with "1,177 spike on your resource group yesterday. Was this intentional?" usually gets a same-day response. Document the response, even a one-line Teams reply, as the attribution record.

3. Decide: update the forecast or track the waste

Once the owner responds, the finance decision is binary. If the spike was intentional (a feature launch, a training run, a marketing event), log the reason and update the relevant subscription's forecast for however long the elevated spend is expected to continue. If it was accidental (a forgotten test rig, an autoscale bug), log it as waste-to-recover and track the subscription in Cost analysis until next-day spend returns to the expected band. Both outcomes need a record; the worst outcome is an anomaly that closes without any note.

4. Set the alerts and the response SLA

Lean on what Azure gives you for free: ensure a scheduled anomaly alert emails the model's detections, and add a Budgets alert as a separate threshold backstop. Then anomalies over a materiality threshold (e.g., any single-day variance above 500, or any anomaly persisting 3 days or more) should have a response SLA of four business hours for owner identification and 24 hours for a documented disposition (intentional / accidental / under investigation). The ratio of anomalies closed with an attribution note within SLA is the leading indicator of how well the accountability loop is working.

Quick quiz

Question 1 of 5

An anomaly has been open for 8 days: the subscription is running 1,177 per day above expected and Cost analysis has flagged it on each of those days. No owner has responded. What is the right finance move?

Keep learning

Dig deeper into Azure cost anomaly detection, the attribution workflow, and how Budgets complement it.

You have finished the finance partner's view of Azure cost anomaly investigation. You know detection is free and automatic, so the value is all in the response: convert a daily variance into a run-rate exposure, identify the resource-group owner before escalating, log the disposition (intentional spend or waste-to-recover) for the audit trail, and lean on the scheduled anomaly alert plus a Budgets backstop. Next time an anomaly sits open for three days, you will have the framing to escalate it without waiting for engineering to notice.

Back to the library

Azure cost anomalies: the headline

The bill changed materially: does the organisation know why?

An Azure cost anomaly means the spend for a subscription moved well outside what Cost Management expected from recent history. The roughly 7x spike in this lesson's example (188 per day expected, 1,366 per day actual) is not necessarily a problem. It might be a planned capacity event. What it is, definitively, is a change the organisation should be able to explain.

The leadership question is not technical: it is whether there is a named owner who knows why spend moved, and whether that information reached finance in time to update the forecast. Anomalies that sit unanswered for weeks become the surprise line items at the next quarterly review. The maturity signal is speed of attribution: the best-run teams close every anomaly with a one-sentence owner response within 24 hours, turning a potential 35k monthly surprise into a small one-off. The detection is free; the value is the response.

A short read on why Azure cost anomalies are a leadership concern even when the amounts seem small. You will understand the one question an anomaly always demands an answer to (does this organisation know why the bill changed?) and what a mature anomaly-response culture looks like: fast attribution, a named owner, and a one-sentence closure note. No technical depth needed.

Fun fact

The most expensive bug is the one nobody owns

What this anomaly looks like from the top

The same Friday-morning anomaly lands in the leadership digest: a 1,177 single-day cost spike on the production subscription, concentrated in the ML Research resource group. The operational question (what resource, which team) was answered inside an hour. K. Tanaka launched two GPU virtual machines for a training run; they are expected down by Sunday. Finance has the note.

The thing worth tracking at leadership level is not this specific anomaly, it is whether the pattern holds. Did the team close it within 24 hours? Yes. Did the owner respond with a one-sentence explanation? Yes. Did finance get the information they needed to update the forecast if the run extends? Yes. That is exactly the anomaly-response culture that keeps a small spike from becoming a 35k surprise on the quarterly review slide.

The maturity signal is not zero anomalies, it is that every anomaly has a named owner and a one-line closure note. The detection itself is free and automatic; what costs the organisation is silence. When the digest starts showing anomalies that sat unanswered for five days, that is the governance gap to address.

Why unattributed anomalies are a governance gap, not just a cost issue

An anomaly that nobody investigates within 24 hours is a signal about how the organisation governs cloud spending, not just a line on the bill. The amount in isolation (1,177 on day one) is manageable. What it tests is whether there is a functioning accountability loop: a named owner per subscription, a process for claiming an anomaly, and a closed-loop response that reaches finance before the month-end actuals land. The detection is already done for you and free; only the loop is missing.

When that loop does not exist, the second-order cost is more damaging than the first. Unattributed anomalies pollute the spend data that informs capacity planning, reservation commitments, and budget forecasts. Six weeks of unacknowledged anomalous spend can skew the numbers that drive substantial annual commitment decisions, at which point the 35k anomaly has a much larger tail.

The trust impact compounds the financial one. Finance partners who stop trusting cloud spend forecasts because anomalies frequently go unexplained start requiring manual sign-off on every cloud spend increase, slowing engineering velocity as a side effect. Engineering teams who stop trusting the alert channel because alerts rarely get acknowledged start muting notifications, eliminating the early-warning system entirely. Both outcomes are self-inflicted and preventable by the same process: a fast, consistent, documented response to every anomaly over a materiality threshold.

The leadership frame for anomaly response

The executive's role is not to triage individual spikes, it is to ensure the organisation has the process and accountability structure that makes fast triage the default. The detection is free; the response is the lever. Three of them.

1. Require a named owner per subscription

Every subscription and resource group should map to a named team or cost centre, and that mapping should be current and queryable through tags. Anomaly attribution fails at the first step when "who owns this?" does not have an instant answer. A maintained owner-tagging policy is the foundation the whole triage loop rests on, and it is the only investment the free detection asks of you.

2. Turn on the free alerting and set a public SLA

Make sure scheduled anomaly alerts are enabled on every subscription (they cost nothing) and add Budgets alerts as a threshold backstop. Then publish a response-time expectation for anomalies over a materiality threshold: for example, any anomaly over 500 variance gets an owner claim within four business hours and a disposition note within 24. Review the SLA compliance rate monthly. The number itself matters less than the act of measuring it: teams that know anomaly-response time is tracked respond faster.

3. Treat the post-mortem library as institutional memory

Recurring anomaly patterns (GPU virtual machines left running over weekends, cross-region data transfer spikes, autoscale rules that never scale back down) compound until they are named and documented. Ask the FinOps team to maintain a one-liner-per-anomaly log and reference it when the same pattern fires again. The second occurrence of any anomaly type should take thirty seconds to triage, not thirty minutes.

Quick quiz

Question 1 of 5

Your FinOps team reports that last month 60% of anomalies over 500 variance were closed within 24 hours with an attribution note; 40% drifted for more than 5 days with no response. What is the right read?

Keep learning

Dig deeper into Azure cost anomaly detection, the attribution workflow, and how Budgets complement it.

That is the lesson. Two things to carry forward: Azure already detects cost anomalies for free on every subscription, so every anomaly is a test of whether the organisation has a functioning ownership loop, a named owner per resource group, a fast attribution, and a one-line disposition that reaches finance before month-end. And the leading indicator of that loop's health is a single metric: the share of anomalies over your materiality threshold that close with an attribution note within 24 hours. When that number is high, surprises at the quarterly review get rarer. When it is low, that is the governance gap to fix.

Back to the library

Investigate an Azure cost anomaly

Azure cost anomalies: the basics

The most expensive bug is the one nobody owns

Triaging an Azure cost anomaly in action

How Azure cost anomaly detection actually worksdeep dive

What is the impact of unattributed Azure cost anomalies?

How do you triage and act on an Azure cost anomaly?

1. Attribute: find the resource and the owner

2. Diagnose: usage change or rate change?

3. Decide: intentional or accidental?

4. Layer the alerts and write the one-liner

Quick quiz

Keep learning

Azure cost anomalies: what finance needs to know

The most expensive bug is the one nobody owns

How a finance partner moves through an anomaly insight

The financial exposure of an unattributed anomaly

The finance partner's triage loop for an Azure cost anomaly

1. Convert variance to run-rate exposure

2. Check ownership before escalating

3. Decide: update the forecast or track the waste

4. Set the alerts and the response SLA

Quick quiz

Keep learning

Azure cost anomalies: the headline

The most expensive bug is the one nobody owns

What this anomaly looks like from the top

Why unattributed anomalies are a governance gap, not just a cost issue

The leadership frame for anomaly response

1. Require a named owner per subscription

2. Turn on the free alerting and set a public SLA

3. Treat the post-mortem library as institutional memory

Quick quiz

Keep learning

Related cost lessons