ms-ai-architect/skills/ms-ai-governance/references/monitoring-observability/alerting-strategies-escalation.md

Alerting Strategies and Escalation Policies for AI Incidents

Last updated: 2026-05 Status: GA Category: Monitoring & Observability

---

Introduksjon

Effektive alerting-strategier og eskaleringsrutiner er kritiske for å sikre rask respons på AI-relaterte hendelser. I motsetning til tradisjonelle applikasjoner introduserer AI-systemer unike utfordringer: modeller kan degradere over tid (drift), prompt injection-angrep kan oppstå plutselig, og token-kostnader kan eksplodere uten varsel. En robust alerting-arkitektur må derfor kombinere reaktive varsler (noe gikk galt) med proaktive varsler (noe er i ferd med å gå galt).

Azure Monitor gir et omfattende rammeverk for alerting gjennom action groups, alert processing rules, og integrasjon med Azure Automation, Logic Apps, og ITSM-systemer. For AI-løsninger må denne infrastrukturen konfigureres med forståelse av både business impact og teknisk kompleksitet — en kritisk alert kan være en modell som returnerer bias-innhold, eller en Azure OpenAI-deployment som nærmer seg rate limit.

Eskaleringsrutiner må reflektere organisasjonens modenhetsnivå. En Minimum Viable Product (MVP)-løsning kan starte med e-postvarsler til et lite team, mens en produksjonsløsning for offentlig sektor krever Multi-tier escalation med clear ownership, automated incident response, og compliance logging for AI Act Article 72 (incident reporting).

---

Kjernekomponenter

Azure Monitor Alert Architecture

Komponent	Beskrivelse	AI-relevans
Alert Rules	Definerer betingelser som trigger alerts (metrics, logs, activity log)	Token rate limits, model latency, failed requests
Action Groups	Samling av notifications og actions som kjøres når alert fires	Email, SMS, webhook, runbook, Logic App
Alert Processing Rules	Overstyr eller berik alert-oppførsel (suppression, tillegg av action groups, scheduling). Filtre støtter opptil 5 verdier per filter (logisk OR). Suppression har høyere prioritet enn Apply action groups.	Prevent alert fatigue under model redeployments; recurring maintenance windows (Verified MCP 2026-04)
Common Alert Schema	Uniform JSON payload på tvers av alle alert-typer	Forenkler webhook-integrasjoner og ITSM-connectors
Severity Levels	Sev 0 (Critical) til Sev 4 (Informational)	Map til business impact (Sev 0 = PII leak, Sev 4 = latency spike)

Notification Channels

Channel	Bruksområde	Rate Limits	Global Resilience
Email	Standard notification (opptil 1000 mottakere per action group)	Best practices: Ikke send til personlige adresser, bruk distribution lists	✅ Yes
SMS	Kritiske alerts (begrensede land)	1 SMS per 5 min per nummer	✅ Yes
Voice Call	Sev 0 incidents (natt/helg)	1 call per 5 min per nummer	✅ Yes
Webhook	Integration med eksterne systemer (PagerDuty, Slack)	Retry: 5 retries med 5-40s delay	❌ Endpoint-dependent
Azure App Push	Mobile notifications til Azure-appen	Begrenset til Azure mobile app	✅ Yes
Event Hub	Stream alerts til analytics/SIEM	Supports Private Link og NSP	✅ Yes (regional)

Reusability: Du kan legge til opptil 5 action groups per alert rule. Action groups kjøres concurrent (ingen bestemt rekkefølge). Multiple alert rules kan bruke samme action group. (Verified MCP 2026-04)

Rate Limiting: Azure Monitor rate-limiter notifications for å hindre spam. Hvis samme email/SMS/telefonnummer mottar for mange alerts, suspenderes notifications midlertidig. For AI-systemer som kan generere høy alert-volum (f.eks. per-request failures), bruk programmatic actions (Logic Apps, Automation Runbooks) i stedet.

Action Types for AI Incidents

{
  "actionType": "AutomationRunbook",
  "runbookName": "ScaleDownOpenAI",
  "webhookResourceId": "/subscriptions/.../runbooktest/webhooks/Alert...",
  "useCommonAlertSchema": true,
  "isGlobalRunbook": false
}

Action Type	AI Use Case	Authentication	Managed Identity	Cross-tenant Support
Automation Runbook	Auto-scale Azure OpenAI TPM, restart failing deployments	Managed Identity (Automation Contributor, Role ID: f353d9bd)	✅ Yes	❌ No
Logic App	Enrich alert med model metadata, post til Teams/Slack	Managed Identity (Logic App Contributor, Role ID: 87a39d53)	✅ Yes	❌ No
Azure Function	Custom logic (e.g., invoke model rollback API)	HTTP trigger med access key	❌ No	❌ No
Webhook	Invoke external incident mgmt (PagerDuty, ServiceNow)	Basic auth via URI eller secure webhook (Entra ID)	❌ No	✅ Yes (limited)
Event Hub	Stream til SIEM (Microsoft Sentinel) for correlation	Managed Identity (Event Hubs Data Sender, Role ID: 2b629674)	✅ Yes	✅ Yes (up to API 2023-09-01-preview)
Secure Webhook	Invoke protected API med Entra ID-auth	Microsoft Entra app registration	❌ No	✅ Yes
ITSM Connector	Create incidents i ServiceNow, Cherwell	ITSM connection credentials	❌ No	❌ No

(Verified MCP 2026-04)

Managed Identity Best Practice (preview): Managed Identity-støtte for Action Groups er nå tilgjengelig i preview. For Automation Runbooks, Logic Apps og Event Hubs, bruk managed identity i stedet for service principals. Azure Function, Webhook, Secure Webhook og ITSM støtter ikke managed identity — bruk HTTP trigger access key respektive secure webhook med Entra ID. Azure Portal legger automatisk til role assignments ved konfigurasjon. For PowerShell/CLI/SDK må du manuelt tildele roller (se tabell over). (Verified MCP 2026-04)

---

Arkitekturmønstre

1. Multi-Tier Escalation for AI Incidents

Bruk når: Produksjonsløsninger med SLA-krav og 24/7 support.

Implementering:

Tier 1: On-Call Developer (Email + SMS)
  ├─ Sev 3-4 alerts → Respond within 4 hours
  └─ Auto-escalate to Tier 2 if no ACK within 30 min

Tier 2: AI Platform Team (Voice Call + PagerDuty)
  ├─ Sev 1-2 alerts → Respond within 30 min
  └─ Auto-escalate to Tier 3 if no resolution within 2 hours

Tier 3: Management + Legal (Email + Teams)
  └─ Sev 0 alerts → Data breach, AI Act violation, PII leak

Azure Monitor Implementering:

1. Action Group per Tier:

   • AG-Tier1-Developers: Email til dev-team distribution list
   • AG-Tier2-Platform: SMS + PagerDuty webhook
   • AG-Tier3-Executive: Voice call til on-call manager + Teams notification

2. Alert Processing Rule for Auto-Escalation:

   {
     "rules": {
       "if": "alert.severity == 0 AND alert.state == 'New' FOR 30 minutes",
       "then": "add action group AG-Tier3-Executive"
     }
   }
   

3. Time-Based Escalation (via Logic App):

   • Webhook til Logic App som sjekker alert timestamp
   • Hvis ikke acknowledged innen threshold → invoke Tier 2/3 action groups

Fordeler:

• Clear ownership per severity level
• Reduserer alert fatigue for Tier 3
• Automatisk eskalering hindrer at kritiske alerts "faller mellom stolene"

Ulemper:

• Kompleks konfigurasjon (krever Logic Apps for time-based escalation)
• Krever testing og dokumentasjon av eskaleringsrutiner
• Risiko for "false escalations" hvis thresholds er feil satt

---

2. Automated Remediation with Runbooks

Bruk når: Kjente failure modes med deterministiske fix-prosedyrer (scale-out, restart, rollback).

Eksempel: Azure OpenAI deployment nærmer seg TPM limit → Auto-scale til høyere tier.

Runbook Template (PowerShell 7):

param(
    [object] $WebhookData
)

# Parse Common Alert Schema
$alertData = (ConvertFrom-Json -InputObject $WebhookData.RequestBody)
$resourceId = $alertData.data.essentials.alertTargetIds[0]
$metricValue = $alertData.data.alertContext.condition.allOf[0].metricValue

# Extract OpenAI deployment info
$deployment = $resourceId -split '/' | Select-Object -Last 1
$rgName = ($resourceId -split '/')[4]

# Scale up to Standard tier if approaching limit
if ($metricValue -gt 8000) {
    Update-AzCognitiveServicesAccount -ResourceGroupName $rgName `
        -Name $deployment -Sku "S0" -Force
    Write-Output "Scaled $deployment to S0 tier"
}

Alert Rule Configuration:

Metric	Threshold	Action
TokensPerMinute	> 8000 (80% of 10K limit)	Invoke runbook ScaleUpOpenAI
RequestLatency	> 5000ms for 5 min	Invoke runbook RestartDeployment
FailedRequests	> 50 in 10 min	Send to Logic App for root cause analysis

Fordeler:

• Reduserer Mean Time To Recovery (MTTR) dramatisk
• Fungerer 24/7 uten manuell inngripen
• Audit trail via Automation job logs

Ulemper:

• Runbooks må testes grundig (feil logic kan forverres situasjonen)
• Krever Automation Contributor role på ressursene
• Ikke egnet for komplekse diagnostiseringsscenarioer

---

3. Stateful vs. Stateless Alerting for AI Workloads

Problem: AI-requests kan generere tusenvis av failed requests ved samme rot-årsak (f.eks. model deployment down). Skal vi sende ett alert eller tusenvis?

Stateful Alerting (anbefalt for AI):

• Enable: Automatically resolve alerts = true
• Behavior: Ett alert fires når condition blir true, auto-resolves når condition blir false
• Bruk når: Infrastruktur-alerts (deployment down, API unavailable)

Stateless Alerting:

• Enable: Automatically resolve alerts = false
• Behavior: Nytt alert for hver evaluation cycle som matcher condition
• Bruk når: Per-request monitoring (track hver PII leak, hver toxic content response)

Azure AI-spesifikk konfigurasjon:

Alert Rule	Type	Rationale
Azure OpenAI Deployment Unavailable	Stateful	En deployment er enten oppe eller nede — send ett alert
Prompt Injection Detected	Stateless	Hver deteksjon skal logges individuelt (compliance)
Content Safety Filter Triggered	Stateless	Hver toxic response er en separat incident
Token Rate Limit Approaching	Stateful	Send warning når 80% nådd, resolve når < 70%

---

Beslutningsveiledning

Severity Mapping for AI Incidents

Severity	Definition	AI Examples	SLA	Escalation
Sev 0	Total service outage eller critical security breach	PII leak, AI Act violation, all models unavailable	< 15 min response	Tier 3 immediate
Sev 1	Major degradation affecting production workload	Primary model down, >50% error rate	< 30 min response	Tier 2 + manager notify
Sev 2	Partial degradation, workaround available	Secondary model down, latency >5s	< 2 hour response	Tier 2
Sev 3	Minor issue, no user impact	Token costs 20% above budget	< 8 hour response	Tier 1
Sev 4	Informational, proactive monitoring	Model drift detected, new version available	No SLA	Email only

Notification Channel Decision Tree

START: AI Alert Fired
  │
  ├─ Is it Sev 0/1? ───YES──> SMS + Voice Call + Teams (immediate)
  │                     │
  │                     └─> Add webhook to PagerDuty/ServiceNow
  │
  └─ Is it Sev 2/3? ───YES──> Email + Teams channel
      │
      └─> Is it business hours? ───NO──> Add SMS for Sev 2
                                   │
                                   YES─> Email only

Anbefalinger fra Well-Architected Framework

(Verified MCP 2026-04)

Anbefaling	Fordel
Bruk dynamic thresholds i metric alerts	ML-baserte terskler tilpasser seg automatisk — unngår manuell threshold-tuning for AI-workloads med variabelt load
Bruk managed identity for log search alert rules	Credential-free auth; påkrevd hvis query aksesserer Azure Data Explorer (ADX) eller Azure Resource Graph (ARG)
Bruk custom properties i alert rules	Legg til metadata (owner, cost center, AI Act reportable) i alert payload — enklere triaging og compliance-logging
Bruk Logic Apps for enrichment	Customiser notification-format, hent tags fra ressurser, integrer med Teams/Slack/PagerDuty uten å endre alert rule
Activity log alerts er gratis	Bruk activity log alerts for administrative hendelser der mulig — ingen kostnad per evaluering

Vanlige Feil (Red Flags)

Anti-pattern	Problem	Anbefaling
Sending all alerts to personal email	Vacation/sickness = ingen response	Bruk distribution lists eller action groups per team
No severity differentiation	Alert fatigue — alt er "viktig"	Implementer 5-tier severity model
No auto-escalation	Critical alerts blir ignorert nattestid	Logic App med time-based escalation til manager
Email-only for Sev 0	Delays i critical situations	SMS + Voice Call for Sev 0/1
No actionable context	Alerts sier "something is wrong" uten details	Custom properties med resource metadata, query results
Alerting on every request failure	Stateless alerts → spam	Bruk stateful alerts + aggregation windows (5-15 min)

Recommended Alert Rules for Azure AI Services

Service	Metric/Log	Threshold	Action
Azure OpenAI	azure.openai.requests (429 errors)	> 10 in 5 min	Scale up deployment tier
Azure OpenAI	TokensPerMinute	> 80% of quota	Email warning + runbook to request quota increase
Azure AI Search	SearchLatency	> 1000ms for 10 min	Check index size, scale up replicas
Content Safety	ModeratedContent (high severity)	Any occurrence	Stateless alert + SIEM integration
Document Intelligence	FailedRequests	> 20% error rate	Check API version compatibility, model availability

---

Integrasjon med Microsoft-stakken

Azure Monitor ↔ Microsoft Sentinel

Bruk: Stream AI-alerts til Sentinel for correlation med security events.

Konfigurasjon:

1. Action Group → Event Hub:

   {
     "eventHubReceiver": {
       "name": "SentinelEventHub",
       "subscriptionId": "...",
       "eventHubNameSpace": "ai-monitoring",
       "eventHubName": "alerts",
       "useCommonAlertSchema": true
     }
   }
   

2. Sentinel Data Connector:

   • Connect til Event Hub
   • Parse Common Alert Schema
   • Correlate med AuditLogs, SignInLogs for user context

Fordeler:

• Single pane of glass for security + operational monitoring
• Advanced threat detection (e.g., prompt injection patterns + user behavior anomalies)
• Compliance reporting (AI Act Article 72)

Azure Monitor ↔ Logic Apps

Bruk: Enrich alerts med kontekstuell informasjon før notification.

Eksempel Workflow:

Alert: "Azure OpenAI High Error Rate" (Sev 2)
  ↓
Logic App receives webhook
  ↓
Query Log Analytics for last 100 error messages
  ↓
Group by error code (401, 429, 500)
  ↓
Fetch deployment tags (owner, cost center, environment)
  ↓
POST enriched alert til Teams:
  "🔴 Sev 2: Azure OpenAI Errors
   Deployment: gpt-4-prod
   Owner: ai-platform-team@company.com
   Top Errors: 429 (80%), 500 (15%), 401 (5%)
   Cost Center: CC-12345
   Environment: Production
   Runbook: aka.ms/fix-429-errors"

Template Actions:

1. HTTP (Get Model Metadata): Call Azure OpenAI Management API for deployment details
2. Log Analytics (Query Errors): AzureDiagnostics | where Category == "RequestResponse" and httpStatusCode_d >= 400
3. Teams (Post Adaptive Card): Rich notification med buttons ("Acknowledge", "View Logs", "Run Remediation")

Azure Monitor ↔ Azure Automation

Bruk: Auto-remediation for infrastruktur-alerts.

Common Runbooks for AI:

Runbook	Trigger Alert	Action
ScaleUpOpenAI	TokensPerMinute > 80%	Update deployment tier (PTU → PTU-M)
RestartFailedDeployment	Health probe failed	Delete + redeploy model
NotifyCompliance	Content Safety violation	Email legal + log to compliance database
RollbackModel	Error rate > 50% after deployment	Swap to previous model version

Managed Identity Setup:

# Enable System-Assigned Managed Identity on Automation Account
Set-AzAutomationAccount -ResourceGroupName "rg-automation" `
    -Name "ai-automation" -AssignSystemIdentity

# Assign Contributor role to Managed Identity
$automationAccount = Get-AzAutomationAccount -ResourceGroupName "rg-automation" -Name "ai-automation"
New-AzRoleAssignment -ObjectId $automationAccount.Identity.PrincipalId `
    -RoleDefinitionName "Contributor" -Scope "/subscriptions/.../resourceGroups/rg-ai"

---

Offentlig sektor (Norge)

AI Act Article 72: Incident Reporting

EU AI Act krever at providers rapporterer "serious incidents" til nasjonale myndigheter innen 15 dager. Azure Monitor alerts må derfor konfigureres med compliance logging.

Serious Incident Definition (AI Act):

• Death or serious injury
• Serious harm to health, property, or environment
• Serious violation of fundamental rights (e.g., discrimination)

Implementering:

1. Tag Critical Alerts:

   {
     "customProperties": {
       "aiActReportable": "true",
       "incidentType": "discriminationRisk",
       "affectedUsers": "approx. 500",
       "dataProcessed": "PII (names, addresses)"
     }
   }
   

2. Action Group → Event Hub → Archive Storage:

   • Stream til immutable blob storage (compliance retention)
   • Hourly export til Sentinel for analysis
   • Monthly report generation (Logic App)

3. Notification til Compliance Officer:

   • Sev 0 alerts → immediate email til DPO + legal
   • Include pre-filled incident report template

Forvaltningsloven § 25 (Begrunnelsesplikt)

Vedtak fattet med AI-støtte må kunne forklares. Hvis AI-modellen feiler under saksbehandling, må dette logges og eskaleres.

Alert Rule: "AI Recommendation Unavailable During Case Processing"

Action:

1. Immediate: Email til saksbehandler (manual fallback)
2. Within 1 hour: Notify IT support
3. Within 4 hours: Incident report til seksjonsleder
4. Audit log: Store case ID, timestamp, error message (for later review)

Schrems II / Data Residency

Alerts som inneholder PII må ikke sendes til tjenester utenfor EU/EØS. Dette gjelder spesielt webhooks til SaaS-løsninger (PagerDuty, Slack).

Compliant Setup:

Notification Channel	Data Residency	Compliant?	Alternative
Email (Microsoft 365 EU tenant)	EU	✅ Yes	—
Teams (EU datacenter)	EU	✅ Yes	—
Event Hub → Sentinel (Norway East)	Norway	✅ Yes	—
Webhook → PagerDuty (US)	USA	❌ No	Bruk Logic App i Norway East som proxy, strip PII
SMS (Twilio US)	USA	❌ No	Bruk Azure Communication Services (EU)

Best Practice: Bruk customProperties til å skille mellom metadata (OK å sende ut) og PII (må holdes innenfor EU).

---

Kostnad og lisensiering

Azure Monitor Alerts Pricing (Norway East, Feb 2026)

Alert Type	Price per Rule/Month	Price per Evaluation	Notes
Metric Alert (standard)	0.10 USD	—	First 10 rules free per subscription
Metric Alert (multi-resource)	0.10 USD	—	Can monitor 1000+ VMs with one rule
Log Search Alert	0.10 USD	0.20 USD per query execution	Frequency × time window = cost
Activity Log Alert	FREE	FREE	Use these whenever possible!
Service Health Alert	FREE	FREE	—
Resource Health Alert	FREE	FREE	—

Example Cost Calculation (Log Search Alert):

Alert: "Azure OpenAI Error Rate > 10%"
Query frequency: Every 5 minutes
Time window: 15 minutes
Evaluations per month: (60/5) × 24 × 30 = 8640

Cost = 0.10 USD (rule) + (8640 × 0.20 USD) = 1728.10 USD/month

Optimization Strategy:

• Bruk metric alerts i stedet for log search alerts der mulig (gratis evaluations)
• Bruk activity log alerts for administrative events (gratis)
• Bruk multi-resource alert rules (én rule for mange ressurser)
• Øk query frequency til 15-30 min for non-critical alerts

Action Group Pricing

Action Type	Cost	Rate Limit
Email	FREE	1000 emails per hour per action group
SMS	0.20 USD per SMS	1 SMS per 5 min per phone number
Voice Call	1.00 USD per call	1 call per 5 min per phone number
Webhook	FREE	—
Automation Runbook	Automation job cost (0.002 USD per minute)	—
Logic App	Logic App execution cost (varies)	—
Event Hub	Event Hub ingress cost (0.028 USD per million events)	—

Best Practice: Start med email + webhook (free), legg til SMS/voice call kun for Sev 0/1.

---

For arkitekten (Cosmo)

Spørsmål å stille kunden

1. Severity Mapping:

   • "Hva definerer dere som en Sev 0 incident for deres AI-løsning? PII leak? Total nedetid? Noe annet?"
   • "Hva er akseptabel Mean Time To Acknowledge (MTTA) per severity level?"

2. Escalation Procedures:

   • "Har dere en on-call rotation? Hvem skal motta SMS/voice call ved nattestid for Sev 0/1?"
   • "Skal management (seksjonsleder, DPO, juridisk) varsles automatisk ved visse typer alerts?"

3. Compliance Requirements:

   • "Er løsningen omfattet av AI Act som high-risk system? Må dere rapportere serious incidents til myndighetene?"
   • "Hvilke data residency-krav har dere? Er det OK å sende alerts til webhooks utenfor EU/EØS?"

4. Automation vs. Manual Response:

   • "Er det failure modes hvor dere ønsker automatisk remediation (scale-up, restart)? Hva er risikoen ved feil automation?"
   • "Hvilke alerts krever manuell triaging før action (f.eks. model rollback)?"

5. Integration Points:

   • "Bruker dere ITSM-system (ServiceNow, Cherwell)? Skal alerts automatisk opprette incidents?"
   • "Skal alerts streames til Sentinel for security correlation? Til Power BI for dashboards?"

6. Alert Fatigue:

   • "Hvor mange alerts får dere per dag i dag? Hvor mange av dem er actionable?"
   • "Er det alerts dere ignorerer fordi de 'alltid fyrer'? Hvordan kan vi redusere false positives?"

7. Testing & Validation:

   • "Hvordan skal vi teste eskaleringsrutinene før go-live? Ønsker dere en tabletop exercise?"
   • "Hva er akseptabel alert latency (tid fra incident → alert fires)? 1 min? 5 min?"

Fallgruver å unngå

Fallgruve	Konsekvens	Mitigering
Alert spam (100+ alerts per dag)	Team ignorer alle alerts	Bruk stateful alerts, øk aggregation windows, implementer alert processing rules
No clear ownership	Alerts går til "no-reply" inbox som ingen sjekker	Definer action groups per team/severity, bruk distribution lists
Over-reliance på automation	Runbook scaler opp feil ressurs → cost explosion	Start med manual approval workflows, test automation grundig
PII i alert payload	GDPR violation når sendt til external webhooks	Bruk customProperties for metadata only, strip PII i Logic App proxy
No escalation for unacknowledged alerts	Sev 0 alerts blir ikke sett nattestid	Implementer time-based escalation via Logic App
Webhook endpoints without retry logic	Alerts tapt hvis endpoint er midlertidig nede	Bruk Event Hub som buffer + reliable delivery
Cost blindness	Log search alerts med 1-min frequency → 1000+ USD/month	Bruk metric alerts der mulig, øk query frequency til 5-15 min

Anbefalinger per modenhetsnivå

Level 1 (MVP / Pilot):

• 1 action group med email til dev-team
• Metric alerts for kritiske metrics (availability, error rate)
• Stateful alerting for infrastruktur-events
• Severity: Kun Sev 1/2/3 (simplifisert)

Level 2 (Production / Basic Maturity):

• Multi-tier escalation (developer → platform team → manager)
• SMS + voice call for Sev 0/1
• Integration med Teams for collaborative triaging
• Alert processing rules for maintenance windows
• Automation runbooks for simple remediation (scale-up)

Level 3 (High Maturity / Regulated):

• Full 5-tier severity model med SLA per level
• ITSM integration (auto-create ServiceNow incidents)
• Sentinel integration for security correlation
• Compliance logging (AI Act incident reporting)
• Advanced automation (model rollback, canary deployments)
• Quarterly alert review + optimization (reduce alert fatigue)

Level 4 (Best-in-Class / Autonomous):

• AI-powered alert correlation (AIOps)
• Predictive alerting (model drift detected before user impact)
• Closed-loop remediation (auto-resolve 80%+ of alerts)
• Real-time cost optimization (auto-scale based on budget vs. demand)
• Continuous compliance monitoring (automated AI Act Article 72 reporting)

---

Kilder og verifisering

Verified (from Microsoft Learn MCP)

1. Action Groups Overview https://learn.microsoft.com/en-us/azure/azure-monitor/alerts/action-groups Confidence: High — Official documentation retrieved 2026-02, covers notification types, managed identity, rate limits.

2. Best Practices for Azure Monitor Alerts https://learn.microsoft.com/en-us/azure/azure-monitor/alerts/best-practices-alerts Confidence: High — Well-Architected Framework guidance, includes reliability, cost optimization, operational excellence.

3. Webhook Retry Logic https://learn.microsoft.com/en-us/azure/azure-monitor/alerts/action-groups#webhook Confidence: High — Documented retry intervals (5s, 20s, 5s, 40s, 5s) and 15-min cooldown.

4. Automation Runbook with Managed Identity https://learn.microsoft.com/en-us/azure/automation/automation-create-alert-triggered-runbook Confidence: High — Code sample for VM stop runbook using Common Alert Schema.

5. Alert Processing Rules https://learn.microsoft.com/en-us/azure/azure-monitor/alerts/alerts-processing-rules Confidence: High — Covers suppression, action group override, scheduling.

6. Stateful vs. Stateless Alerts https://learn.microsoft.com/en-us/azure/azure-monitor/alerts/alerts-troubleshoot-metric Confidence: High — "Automatically resolve alerts" checkbox behavior explained.

7. Service Limits for Notifications https://learn.microsoft.com/en-us/azure/azure-monitor/alerts/action-groups#service-limits-for-notifications Confidence: High — Rate limits per notification type (SMS, voice, email).

Baseline (Model Knowledge)

8. AI Act Article 72 Incident Reporting Confidence: Medium — EU AI Act text available, but specific implementation guidance for Azure not yet published by Microsoft (as of Feb 2026).

9. Severity Mapping Best Practices Confidence: Medium — Industry standard pattern (Sev 0-4), adapted for AI-specific scenarios based on architecture experience.

10. Multi-Tier Escalation Pattern Confidence: High — Standard ITIL/SRE practice, Azure Monitor supports via action groups + Logic Apps.

Recommendations for Further Verification

• Cost estimates: Verify against Azure Pricing Calculator (pricing kan variere per region og currency fluctuations).
• AI Act compliance: Consult with legal team og Datatilsynet for norsk implementering av EU AI Act Article 72.
• ITSM integration: Test ITSM connector med deres spesifikke ServiceNow/Cherwell-versjon (API compatibility kan variere).