Critical alerts

Which pushes are critical

The event decides, not the level. Two events are delivered as critical alerts: alert.opened, the first page of something nobody has seen yet, and alert.escalated, meaning a rule’s renotify fired or a ladder rung was reached without an ack. A repeat of an open alert (alert.bumped), an ack and a resolve are ordinary notifications, so the interruption is spent once per new alert rather than once per matching line.

An integration’s Send test event is ordinary too, on purpose: it is a button someone pressed, not a new claim on anyone’s attention. So a test that arrives quietly or late, because the phone’s ordinary notifications are held by Deliver Quietly, a Scheduled Summary or a Focus, is working as designed. It proves the chain from service to phone; it says nothing about the critical path.

Enabling it

iOS asks for critical-alert permission separately from ordinary notifications, the first time the app registers for push. The device reports its own answer to the service, and the service sends the critical rendering only to devices that said yes; every other device gets the ordinary one. If you declined, turn it on under Settings → Pingtower → Notifications → Critical Alerts; the app re-registers on next launch.

The answer belongs to the phone, not the account. If the same phone is registered under more than one account, a team’s critical page needs every one of those registrations to say yes, and a registration by an account that is not a member of that team counts as no. So only your own team’s members can make a page to that phone critical, and one no wins. The page still arrives, only without breaking through.

Who receives it

Every device of every member of the tenant, unless the escalation rung names schedules or accounts, in which case only those people. On a paired box, only members whose pairing is live.