Before you begin
- Access to the Azure subscription and resource group Atlas AVD is installed in, with at least the Reader role to view alerts and Contributor to restart the app or change alert routing
- An Atlas administrator account for the in-app steps (System Health and Export Diagnostics)
Where these emails come from
During installation Atlas creates an action group named atlas-avd-ops and about fifteen alert rules, all prefixed "Atlas AVD —", in the same resource group as your Atlas app. The rules read the app's own logs and metrics from the deployment's Log Analytics workspace, so they keep working even when Atlas itself is down. Azure sends the emails from azure-noreply@microsoft.com to the alert email entered during setup, or to the initial administrator if none was entered.
These alerts are about the health of your Atlas AVD deployment. Alerts about your Azure Virtual Desktop environment, such as a full host pool or a session host with high CPU, are configured separately on Atlas's Notifications page (see Setting Up Alerts).
Azure only delivers alerts to an address that has been confirmed. After installation Microsoft Azure sends a "verify your email" message to the alert address; until someone clicks it, no alert emails arrive. The alert rules are created for installs in the commercial Azure cloud; installs in Azure Government (GCC High) don't receive them yet.
Reading an alert email
Each email follows the same pattern. The subject reads Fired or Resolved, then the severity, the alert name, the resource it ran against and the time it fired. In the body:
- Alert name: the Atlas rule that tripped. Look it up in the lists below.
- Severity: Sev0 to Sev2 (see the next section).
- Affected resource: your Atlas Log Analytics workspace (a name such as atlas-la-xxxxx, type microsoft.operationalinsights/workspaces). The rules run their checks against the workspace, so it is named on every alert. It doesn't mean the workspace is broken.
- Description: the short form of the action to take, for example "Action: profile slow queries, add database indexes, scale if under load".
- Fired time and Alert ID: quote both if you contact support.
- View the alert in Azure Monitor opens the alert in the Azure portal, and View query results shows the log rows that made it fire.
You never need to close an alert yourself. Azure re-runs each check on a schedule and sends the Resolved email automatically once the condition has cleared.
How urgent is it?
- Sev0 (critical): Atlas is down, can't read its secrets, or its audit trail is at risk. Act straight away.
- Sev1 (error): Atlas is running but part of it is degraded, such as slow startups, a queue for database connections, or a background job that has stopped retrying. Act the same day.
- Sev2 (warning): a performance or reliability signal worth a look. A single Sev2 that resolves on its own within an hour usually needs no action; one that keeps coming back does.
Critical alerts (Sev0 and Sev1)
- High error rate (more than 5% server errors), Sev0: over 5 minutes and at least 20 requests, more than 5% of Atlas's requests failed with a server error. Check Administration → Platform → System Health → Service Health for an Azure incident, then confirm the Atlas database (the Azure Database for PostgreSQL server in the Atlas resource group) is running and not out of storage. If errors continue for more than 15 minutes, restart the app (below) and contact support.
- App not reporting (no metrics snapshot for 15 minutes), Sev0: Atlas writes a heartbeat to its logs every minute, and none has arrived for 15 minutes. In the Azure portal open the Atlas App Service: if its status is Stopped, start it; if it is Running, restart it and open Log stream to watch it come back. If Atlas is in fact working normally, check that the App Service's Diagnostic settings still send App Service Console Logs to the Atlas workspace; if that setting was removed, the alert can't see the heartbeat.
- Key Vault access denied, Sev0: Key Vault refused the Atlas app's managed identity, so Atlas can't read any secret. In the Azure portal open the Atlas Key Vault → Access control (IAM) and make sure the Atlas App Service's managed identity holds the Key Vault Secrets User role; add it back if it was removed. If the role is there, check the vault's Networking page in case a firewall rule now blocks the app.
- Audit log writes failing (AU-2), Sev0: Atlas can't write to its audit log, almost always because its database is unreachable. Check the database server as for the high error rate alert, then contact support. If you track CMMC or NIST 800-171 controls, record the time window as an audit-logging incident.
- Must-record audit events in dead-letter (AU-2), Sev0: Atlas could not write some security-relevant audit events and has set them aside rather than lose them. Fix the cause (usually the database, as above) and contact support so the held events can be written back to the audit log.
- Cold start over 60s, Sev1: Atlas took more than a minute to start after a restart, scale-out or update. One alert straight after an update is usually harmless. If it repeats, check the database server and the App Service plan size, and send support a diagnostics bundle.
- Database connection pool exhausted, Sev1: for at least 5 of the last 10 minutes, requests have been queueing for a database connection, so Atlas feels slow. Check the database server's CPU and storage in the Azure portal. A restart clears the queue for now; if it comes back, contact support before changing any settings.
- Scheduler loop stopped self-healing, Sev1: one of Atlas's background jobs (autoscaling, cost collection, data retention or snapshots) failed repeatedly and has stopped retrying, so that work is paused. Check System Health for a matching notification and Azure Service Health for an outage, restart the app to start the job again, and contact support if the alert returns.
Warning alerts (Sev2)
- P95 latency over 1s: the slowest 5% of Atlas's page and API requests took longer than a second, in two of the last three 15-minute windows (long-running streams, live connections and report downloads are excluded). Common causes are a burst of heavy activity, a large report, an undersized App Service plan or a busy database. If it fires and resolves only now and then, no action is needed. If it fires every day, look at the App Service plan's CPU and memory in the Azure portal, consider scaling the plan up, and send support a diagnostics bundle covering the slow period.
- App Service plan memory over 80%: the plan hosting Atlas averaged more than 80% memory for 15 minutes. Restarting the app frees memory straight away. If it recurs, scale the plan up, and check whether other apps share the same plan.
- Scheduler jobs failing (5+ failures/hour): background jobs failed five or more times in an hour, usually because of short Azure or database errors that retry on their own. If it repeats, check Azure Service Health and Atlas's connection to your Azure subscription (see Connecting Your Azure Subscription), then contact support.
- Ink signature deploy failure rate over threshold: in Atlas Ink's latest signature sweep at least half of the mailbox deployments failed. The usual causes are missing Exchange admin consent, Microsoft 365 throttling, or Outlook roaming signatures still being on for the tenant. See Turn Off Outlook Roaming Signatures for Atlas Ink. The alert clears after the next healthy sweep.
- Azure subscriptions throttled (ARM circuit open): Azure has been answering Atlas with "too many requests" for one of your subscriptions for 5 minutes or more. Atlas pauses provisioning, cost collection and scaling for that subscription and retries by itself. Look for a large bulk operation or another tool making heavy Azure calls at the same time, and check Azure Service Health. It normally resolves without action.
- Key Vault reads failing: Key Vault reads are failing for a reason other than permissions (a secret is missing, or the vault timed out) in at least 5 of the last 15 minutes. Integrations that use stored secrets, such as Microsoft Graph or email sending, may fail. Check the vault exists and is reachable, and that no secret was deleted (deleted secrets can be recovered from the vault's Secrets list while soft delete keeps them).
- VM self-healing has stopped evaluating: Atlas's VM self-healing (see Smart Recovery) hasn't completed a full health check of your session hosts for about 15 minutes, so unavailable hosts may not be restarted automatically in the meantime. This often follows Azure throttling or a database interruption and clears on the next complete check. If it lasts more than an hour, contact support.
Restarting Atlas
Several alerts are fixed or cleared by restarting the app. In Atlas, open Administration → Platform → System Health and click Restart App Service, then type RESTART to confirm. If Atlas isn't loading, restart it from the Azure portal instead: open the Atlas App Service and click Restart. Users lose their connection to Atlas for a minute or two; desktop sessions on your session hosts are not affected.
An alert that fires and resolves over and over
A Fired email followed by a Resolved email a little later means the condition was true for a short time and then cleared. If the same alert repeats several times a day, treat it as a pattern rather than a series of one-offs: note the times, compare them with scheduled activity (scaling schedules, report exports, image builds, maintenance windows), and send support a diagnostics bundle covering one of the windows.
Atlas tunes these rules as it learns which signals matter, and each Atlas AVD update applies the latest rules to your deployment automatically. You never need to redeploy them by hand.
Change who gets the alerts, or quiet them
To send the alerts to more people or to Teams or Slack, create your own action group in the Azure portal, then add an alert processing rule (Monitor → Alerts → Alert processing rules) scoped to the Atlas resource group that applies your action group to every alert. To pause notifications during planned maintenance, add an alert processing rule that suppresses notifications for a scheduled window.
Use alert processing rules rather than editing the Atlas alert rules or the atlas-avd-ops action group directly: Atlas re-applies its own rule set when an update changes it, which can replace changes made to those resources. A distribution list as the alert email address works too.
Don't delete the alert rules or switch them off to stop the emails. Several of them, such as App not reporting and Key Vault access denied, are the only warning you get when Atlas itself stops working.
When to contact support
Contact support for any Sev0 alert that doesn't resolve within 15 minutes, any alert this page tells you to report, or any alert that keeps coming back. Include the alert name, the fired time and the Alert ID from the email, and attach a diagnostics bundle (Administration → Support → Export Diagnostics) covering the time the alert fired. See Check Your Deployment's Health and Get Help Faster for how to export one.