Azure Monitoring Checklist: What to Track Before Something Breaks

You know what Azure Monitor does. You may already have dashboards. There is still a gap between having monitoring and having monitoring that prevents outages.

Most environments land in one of two failure modes. Alerts fire constantly until people stop reading them, or they fire accurately and too late, after the users have already noticed. This is the configuration that avoids both.

Before you configure a single alert

• A Log Analytics workspace exists in each region where you run resources
• Diagnostic settings are enabled on everything that matters: VMs, App Services, SQL, storage
• The Activity Log is forwarded to Log Analytics, not just sitting in its default retention
• Action groups exist with the channels you actually watch, whether that is email, SMS, Teams or a pager
• Alert processing rules suppress noise during maintenance windows

This is the step most environments get wrong, and it is worth doing by hand once to understand what you are actually turning on. Configure diagnostic settings for Azure resources walks the whole flow.

Compute

Virtual machines

• CPU above 85 percent for five minutes. Sustained load means undersizing or a runaway process.
• Available memory below 500 MB. Swap thrashing starts well before the VM stops responding.
• OS disk IOPS above 90 percent of the limit. Disk throttling produces application slowness that looks exactly like a code problem, and gets debugged as one.
• Heartbeat missing for five minutes. Either the machine is gone or the agent stopped reporting, and both need looking at.
• VM availability metric below 1. Catches platform level problems that are not your fault and are still your outage.

// VMs with sustained high CPU in the last hour
Perf
| where ObjectName == "Processor" and CounterName == "% Processor Time"
| where CounterValue > 85
| summarize avg(CounterValue) by Computer, bin(TimeGenerated, 5m)
| where avg_CounterValue > 85

If that query looks like syntax rather than something you could modify, that is the gap to close first. Every alert rule you write is KQL underneath. Introduction to Kusto Query Language in Log Analytics is the fastest way to stop copying queries and start writing them.

App Service

• HTTP 5xx above 1 percent of requests. Server errors mean the application or the platform underneath it.
• Response time p95 above 2 seconds. Track the 95th percentile, never the average. Averages are very good at hiding the tail where your unhappy users live.
• A sudden 4xx spike. Usually a broken deployment or a contract change, and it will not show up in 5xx.
• Plan CPU or memory above 80 percent, which fires before autoscale reacts rather than after.
• A health check endpoint configured, so Azure can route traffic away from an unhealthy instance instead of into it.

Application Insights is where App Service monitoring stops being guesswork, because you get request traces rather than aggregate counters. Getting started with Application Insights for App Service covers instrumentation and reading the results.

Once the signals exist, they need somewhere to go. Configuring Azure Monitor alerts and action groups is the piece that turns a metric into someone's phone buzzing, and it is worth building once properly rather than assembling under pressure.

Functions

• Any execution failure in a five minute window. Start noisy here and tune down, rather than the reverse.
• Duration p95 approaching the timeout. On the consumption plan, eight minutes against a ten minute ceiling means you are one slow dependency from failing.
• Queue length growing for queue triggered functions, which means consumption is losing to production.
• Cold start latency, if anything user facing depends on it.

Storage

• Availability below 99.9 percent, which usually means throttling rather than an outage.
• End to end latency p99 above 200 ms. Slow storage becomes slow everything, one layer up.
• Throttling responses, the 429s and 503s that say you have hit an IOPS or bandwidth ceiling.
• Capacity approaching quota. Account limits are generous, and individual containers hit performance limits considerably earlier.
• An anonymous access audit, run on a schedule, confirming that every public container is public deliberately.

Networking

• NSG flow logs enabled.
• VPN gateway connection status, alerting on disconnection if anything hybrid depends on it.
• Load balancer health probe failures, which tell you a backend went unhealthy before the users do.
• DDoS mitigation triggers, if you run the protection tier that reports them.
• Connection Monitor configured on the paths you cannot afford to lose.

Security

• Secure Score tracked over time, with an alert on a drop rather than just a dashboard nobody opens.
• Sentinel analytics rules active and matched to your actual threat model.
• Key Vault access logged, with alerting on access patterns that do not fit.
• Sign in risk detections from Entra ID flowing into Sentinel or Log Analytics.
• Resource locks on the things that must not be deleted by accident.

Secret access is the highest value audit trail you can turn on, and the easiest to forget until you need it. Deploying and managing Key Vault covers both the access model and the logging.

Locks are the cheapest protection in Azure and routinely skipped. Implementing resource locks takes half an hour and prevents a category of incident entirely.

Cost

• Budget alerts at 50, 75, 90 and 100 percent of the monthly figure.
• Anomaly detection enabled in Cost Management, which catches the spike you did not think to budget for.
• Cost tags on every resource group, at minimum a team or cost centre.
• Reservation utilisation, alerting below about 80 percent, because unused commitment is money already spent.
• A monthly orphan sweep for unattached disks, idle public IPs and empty resource groups.

The rule that keeps alerts useful

More alerts is not better monitoring. Every rule should survive three questions.

Is it actionable? If nobody can do anything at three in the morning, it must not wake anyone at three in the morning. Send it to a dashboard.

Does it fire before a user notices? If people report the problem first, the threshold is wrong and the alert is just a record of your failure rather than a warning.

Has it fired in the last thirty days? If not, verify it still works. An alert that silently stopped functioning is worse than no alert, because you are relying on it.

Review the rules monthly and tune or delete anything with a false positive rate above roughly a fifth. Alert fatigue is not a personal failing, it is a configuration problem, and it is fixed by deleting things.

Where this shows up in AZ-104

Monitoring and maintenance is a domain in its own right, covering Azure Monitor, Log Analytics, alerting and backup. It is one of the smaller domains by weight and one of the easiest to lift, because the material is concrete and the labs are short.

For a study plan that sequences this properly, see how to use practice exams to pass AZ-104.