Alerts

Alert policies

An alert policy watches one metric on one service and tells you when it crosses a threshold you set. Policies work for apps and managed databases, up to 10 policies per service. You create them from the service's page in the portal or via the API.

What the metrics mean

• CPU % and memory %: the average across your app's running instances, each instance measured against its own reserved CPU and memory. Three instances at 90%, 10%, and 20% read as 40%. Scaling out does not multiply the value, so a threshold that made sense at one instance still makes sense at five.

• Latency (p50 / p95 / p99): available for web-exposed apps only. Measured at the platform edge: the time from when a visitor's request is handed to your app until the response completes. p95 means 95% of requests in the window finished at or under the value; p50 is the median, p99 catches the slowest tail. Thresholds are in milliseconds.

• Restarts: the total number of instance restarts across the whole app within the window. A crash-looping app is the classic catch: "more than 3 restarts in 15 minutes" finds it long before your visitors do.

• Storage % (managed databases): for a managed database, the share of its provisioned disk currently in use. A policy like "above 80%" warns you before the database runs out of room.

One more honest rule: no data, no decision. A stopped app produces no readings, so its policies simply wait. They neither fire nor resolve until data flows again.

Firing and resolving

Policies are evaluated about once a minute:

1. When the value measured over your window crosses the threshold, the policy fires: an alert event is recorded in the service's alert history and notifications go out (subject to the cooldown below).
2. The policy resolves only after sustained recovery: three consecutive clean checks, roughly 3 minutes back under the threshold. One good reading isn't enough; this stops a flapping metric from spamming you.
3. A resolution is announced in the portal. Resolutions are never emailed; email is reserved for problems.

Cooldown: after a policy notifies you, it stays quiet until its cooldown passes (default 15 minutes, configurable per policy), even if it fires, resolves, and fires again in between. The alert history still records every single transition, so nothing is lost; you're just not paged for each one.

Where notifications arrive

The portal, always. Every firing and every resolution lands in the notification bell and the Activity feed, with a deep link to the service. This needs no setup.

Email, three switches must be on:

1. The policy's own email toggle is enabled.
2. Alert emails are enabled account-wide in Settings → Notifications.
3. Your notification email address is verified (below).

When several policies fire in the same minute, they arrive as one digest email, not a flood.

Verifying your notification email

Alert emails are only sent to a verified address; a typo'd address would otherwise silently swallow your alerts:

1. In the portal, open Settings → Notifications and set your notification email.
2. Request verification. A confirmation message is sent to that address (up to 3 requests per hour).
3. Click the link in the message. It is valid for 24 hours and works once; expired or reused links show an error page and you simply request a new one.

Until the address is verified, alerts keep arriving in the portal; only email stays off. The settings page shows the verification state next to the address.