Policies

A notification policy decides which channels an incident reaches, and when. When an incident opens, WireWatch looks for the policy to use in this order:

monitor → service → organisation default

The first one that is set wins outright, and a monitor with its own policy does not merge with its service’s. If none of the three is set there is no policy, so no notification is sent — a quiet monitor is a normal configuration here, not an error and not a warning state.

What a policy contains

• name — free text, and the only part of a policy a human addresses it by.
• min_severity — partial or full, stored verbatim. partial is the default and lets every incident through; full restricts the policy to full outages. This is the policy’s own threshold and the value a new level channel inherits, below.
• levels — an ordered list, starting at level 1. Each level carries a delay_minutes and a set of channels, and each channel in that set carries its own min_severity, again partial or full.

Level 1 is the initial alert. Levels 2 and above are escalation, and their delay_minutes is what the Escalation section below is measured from.

The filter that decides whether a given incident reaches a given channel is the channel’s min_severity, not the policy’s. A channel added to a level without one is stored with the policy’s min_severity copied onto it, so a policy set to full does not quietly notify at partial. That copy happens once, when the level is saved — changing the policy’s min_severity afterwards does not rewrite the channels already stored under it.

Paging channels default to full

A pagerduty or opsgenie channel added without a min_severity is stored as full, whatever the policy’s own min_severity is. A partial outage still notifies your email, slack and webhook channels; it does not page anyone unless you choose that. This applies to every way a channel is added: the level editor on the Policies page (ticking a PagerDuty or Opsgenie channel starts it at Full only), PUT /orgs/:orgId/policies/:policyId/levels, and attaching a channel to a monitor with PUT /orgs/:orgId/monitors/:monitorId/channels/:channelId. The other three types keep the rule above.

A min_severity you send or pick always wins, so a pager set to partial pages on partial outages too.

Two things this does not do:

• It does not change channels that are already stored. A paging channel added before this default existed keeps partial and keeps paging on partial outages. To change one, open the policy, set that channel’s severity to Full only, and save the levels.
• It does not change what an incident’s severity is. A monitor whose every checking location or agent sees it down opens as full — see Incidents — so it reaches a pager left at the default. A pager left at the default does not page for a legacy high incident, nor for an absence (no_data) incident, which stays partial.

Disabled channels

A channel that a level names but that is switched off is skipped for that send. The level is not an error, the policy is not invalid, and the other channels on the same level go out normally — the disabled one is simply not one of them.

Switching a channel off also drops whatever is already queued for it: those notifications go terminal rather than waiting. Switching it back on starts sending again from that moment; it never replays what was dropped while it was off.

Escalation

Level 1 is not escalation. It is the alert sent when the incident opens, with no delay, and its delay_minutes is never read. Escalation is levels 2 and above, and an incident advances one level at a time.

A level’s delay is measured from the moment the incident opened, not from the previous level’s send. Level k becomes due once the sum of delay_minutes for levels 2 through k has elapsed since the incident’s open time.

A three-level policy with delays 0 / 5 / 10 therefore reaches level 2 five minutes after the incident opened and level 3 fifteen minutes after it opened — not ten. If the level-2 notification itself went out late, level 3 does not move with it: the clock belongs to the incident.

Escalating notifies the channels of the level just reached. Escalation reuses the incident’s opening event, so a channel that has already been sent it — at level 1, or at an earlier escalation level — is not sent it a second time.

Escalation stops the moment the incident is acknowledged or resolved. Levels not yet reached are not sent later, and resolving does not first walk through the remaining ones.

A policy with only level 1 never escalates. There is no level 2 for the incident to become due for, and that is a complete policy rather than an incomplete one.

The organisation default escalates exactly like a monitor’s or a service’s policy. Which level is due, when it is due, and which channels it notifies are decided the same way for all three arms of the resolution order. A policy in force only because it is the organisation default carries no restriction of any kind.

Deleting a policy

A policy that is still referenced cannot be deleted: the request is refused with 409 and the reference has to be moved first. There are three ways to hold a reference, and they are one rule rather than three — a monitor that names the policy as its own, a service that names it as its own, and the organisation that has it as its default. Any one of them refuses the delete, with the same status; the organisation default is not exempt and is not a special case.

For a monitor or a service, moving the reference means assigning a different policy, or none.

The organisation’s default is different in one practical respect. It is set once, when the first email address on the organisation is confirmed (see Getting started), and nothing in the dashboard or the API repoints it — so the policy that is your organisation’s default is a policy you cannot delete. You can rename it, replace its levels and channels, mute it and cap it; delete is the only operation it refuses.

A worked example

A service named Checkout groups two monitors, checkout-api and checkout-web. Neither has a policy of its own, so both resolve to the service’s — Checkout on-call, with three levels:

Level	delay_minutes	Channel
1	0	#checkout-alerts, a Slack channel
2	5	oncall-primary, a PagerDuty channel
3	10	oncall-backup, a second PagerDuty channel

checkout-api goes down in every region and its incident opens at 09:00 as full. Both PagerDuty channels were added without a min_severity, so they are full and this incident reaches them; a partial one would stop at #checkout-alerts.

Time	Sent to	Why
09:00	#checkout-alerts	Level 1, when the incident opens, with no delay.
09:05	oncall-primary	Level 2 — delay_minutes 5, measured from 09:00.
09:15	oncall-backup	Level 3 — 5 + 10 = 15 minutes from 09:00, not 10.

Acknowledge the incident at 09:07 and level 3 is never sent. If checkout-web goes down while this is running, that is a second incident with its own clock, resolved through the same service policy.

If one of those sends does not arrive, Suppression is the list of reasons why.