Alert Catalogue¶
What the platform alerts on, by severity and by resource area. Use it to know what to expect in the alert channel, and to decide which alerts need a runbook.
Reference, not a source of truth
This catalogue is condensed from the alerting documentation of the platform. Severities and thresholds are
defaults of the alert definitions and can change between versions. The definitions in the code repository
(infra/deploy/foundation/policies/policy_definitions/alerts/) and the policy compliance view in the Azure portal are
authoritative. How the alerts are deployed is in How alerting works.
The alert design follows the Azure Monitor Baseline Alerts (AMBA). The platform adds activity log alerts for changes to security-relevant resources.
By severity (hub)¶
The hub subscriptions (management, connectivity, identity). Severities 0 to 2 go to the action group, severities 3 and 4 are logged only (Severity).
Severity 0: critical¶
Immediate response. Check your service level for the response time.
| Alert | Resource | Condition |
|---|---|---|
| Firewall health | Azure Firewall | Health below 90% |
| VPN gateway average bandwidth | VPN gateway | Bandwidth below 1 (connectivity issue) |
Severity 1: error¶
High priority. Significant degradation.
| Alert | Resource | Condition |
|---|---|---|
| Storage account availability | Storage account | Availability below 90% |
| Public IP under DDoS attack | Public IP | Attack detected |
| Public IP address VIP availability | Public IP | VIP availability below 1 |
| Virtual network under DDoS attack | Virtual network | Attack detected |
| ExpressRoute CPU utilisation | ExpressRoute gateway | CPU above 80% |
| SNAT port utilisation | Azure Firewall | SNAT ports above 80%, risk of exhausted connections |
Severity 2: warning¶
Capacity and performance thresholds.
| Alert | Resource | Condition |
|---|---|---|
| Automation account total jobs | Automation account | More than 20 jobs |
| Private link utilisation | Private Link (private DNS zone capacity) | Capacity at or above 80% |
| Private link record set | Private Link (private DNS zone record sets) | Record sets at or above 80% |
Severity 3: informational¶
Logged for awareness and troubleshooting. No notification.
| Alert | Resource | Condition |
|---|---|---|
| BGP peer status | Network gateway | Status below 1 |
| VPN gateway tunnel egress and ingress | VPN gateway | Dynamic threshold exceeded |
| VPN gateway tunnel egress and ingress mismatch | VPN gateway | Timestamp mismatch detected |
Severity 4: verbose (audit)¶
Administrative and security events, logged for audit trails. No notification.
| Group | Alerts |
|---|---|
| Create or update | Network security group, network security group rule, policy, policy assignment, firewall rule, security solution |
| Delete | Policy assignment, network security group, network security group rule, Log Analytics workspace, VPN gateway |
| Operational | Log Analytics workspace key regeneration, failed virtual machine patch installation, route table (UDR) update |
| Health | Resource health unhealthy; Service Health advisory, incident, planned maintenance and security advisory |
By initiative¶
The five alert initiatives, and the resource areas they cover. Within one area there are several alerts, usually one per metric.
| Initiative | Scope (management group) | Covers |
|---|---|---|
Alerting-ServiceHealth |
Platform root | Azure Service Health events: incident, advisory, planned maintenance, security advisory |
Alerting-Connectivity |
Platform connectivity | ExpressRoute circuits (BGP and ARP availability, QoS drops, bits in and out), Azure Firewall (health, SNAT port utilisation), VPN gateways and virtual network gateways (BGP peer status, bandwidth, tunnel ingress and egress, packet drops, CPU), private DNS zones (capacity, query volume, record sets), public IP and virtual network DDoS and availability. Activity log alerts for delete of firewall, network security group and VPN gateway, and for route table updates |
Alerting-Management |
Platform management | Automation account jobs, Recovery Services vault backup health, storage account availability, Log Analytics workspace delete and key regeneration |
Alerting-Identity |
Platform identity | Key Vault availability, capacity, latency, requests and delete |
Alerting-LandingZone |
Landing zones | The alerts for the workload subscriptions below the landing zone management groups. It includes alert definitions for virtual machines (see Monitoring rules). Routed through the processing rule in each subscription |
Which initiatives are assigned is set per platform by alerting_management_groups
(Monitoring rules).
Earlier custom alerts¶
Older documentation lists three custom alert groups next to the baseline alerts, with these severities. They are listed here because they may still show up on platforms that were upgraded in steps:
| Group | Examples |
|---|---|
| Security | Create or update and delete of policy assignments, security groups, security rules and security solutions (severities 1 and 2) |
| Virtual machines | Availability (severity 0), CPU and memory utilisation (1), disk read and write bytes and operations, network in and out (2) |
| Application Gateway | Availability (0), capacity, CPU utilisation, health and throughput (1) |
Check the alert definitions of your version to see which of these exist.
What to do with an alert¶
| Severity | Typical handling |
|---|---|
| 0, 1 | Start the incident process. Have a runbook for every critical alert |
| 2 | Plan the work. If it repeats, fix the cause or tune the threshold |
| 3, 4 | Read them in the weekly review and in the monthly health check. Use them to explain what happened |
Do not mute an alert because it is noisy. Find out whether the threshold is wrong, the resource is unhealthy, or the alert belongs in a lower severity, and change it through Monitoring rules or the alert definition in code.