Policies

A policy decides which health rules’ incidents reach which channels, and how that reaches escalate while nobody acknowledges. Health rules decide what is unhealthy without knowing who cares; policies are where that gets decided, so the same rule can page one team and only show up in the portal for another. Create one from Alerts → Policies → New policy.

An incident that matches no policy is not lost; it is recorded and visible in Incidents, and delivered nowhere. Health rules are being evaluated the moment they are enabled, whether or not a policy exists yet; nothing pages until a policy says where.

The legacy Everything in the portal policy is hidden from configuration and counts while it targets only portal channels. Portal visibility is built in, so no policy is needed for it. Historical records remain available; a policy that also targets an external channel stays visible.

Matching

Every health rule, or a picked list, check the box, or pick specific rules by name.

Severity at least, info, warning or critical, filters by the incident’s own severity, which is the highest tier that ended up driving the breach.

Only rules scoped by narrows to rules judged by a particular set of dimensions (target, site_id, and so on), when you want a policy that only picks up, say, per-site rules and not per-target ones.

With labels matches against the labels a rule was given plus the incident’s own scope values, team=network, site_id=bos. This is how a site-specific escalation, or a team’s own subset of rules, gets its own routing without needing its own rule.

Priority decides order when more than one policy could match: lower tried first, and the first match wins unless it says to keep matching, in which case lower-priority policies are also allowed to route the same incident, a way to have both a team-specific policy and a catch-all without one hiding the other.

Notify

Steps are the escalation chain. Step 1 fires immediately on any channels you pick; later steps fire only if still unacknowledged after a chosen delay (5 minutes up to 4 hours), each one strictly later than the last. A policy holds at most five steps.

Acknowledging the incident from its detail page cancels every pending step that has not fired yet. Escalation happens once, automatically, at the delay you chose; there is nothing to click to make it happen, and nothing that stops it except an ack or the incident resolving on its own.

A disabled channel is shown dimmed in the step’s channel picker and is simply skipped at send time, add it back or point the step somewhere else once it is enabled again.

Escalating severity

If an incident’s severity rises while it is still firing (a second condition breaches at critical, say) policies are re-matched against the new severity and step 1 of every newly-matching policy notifies again. This is the same mechanism a fresh incident uses, just triggered by an escalation rather than an open.

What a policy does not yet do

Remind while still firing is on the editor for when repeat reminders ship; saving a value here does not currently cause anything extra to be sent. Today an incident notifies on open, on each escalation step that fires, and on resolve, nothing repeats in between. There is also no quiet hours or maintenance-window suppression yet; see what alerts do not do yet.

Editing and deleting

Disabling a policy stops it matching without deleting it. Deleting one keeps the delivery history of incidents it already routed; the health rules it matched keep being evaluated, and if no other policy picks them up their incidents simply go nowhere from then on.

Next

• Channels: what a step actually notifies
• Health rules: what a policy is matching against
• Incidents: ack, resolve, and the delivery log a policy produced