Paging & Reliability

Paging is the delivery path from an alert or incident to a responder. Reliability shows whether that path reached its target, whether the notification was delivered, and what response followed.

Notification channels

Moneat supports multiple notification channels for on-call alerts:

• Push notifications — via the Moneat mobile app on iOS and Android. Responders can acknowledge and resolve from the notification.
• Slack DMs — direct messages with an Acknowledge button and a View Details link. Open the alert detail page to resolve the alert or continue response work.
• Email — notification emails with an Acknowledge link and an Open the alert link. The acknowledge link opens a page that shows the alert. Press Acknowledge on that page to acknowledge it in your name; opening the link alone changes nothing. Each link works once and expires after 24 hours.
• SMS and voice calls — Twilio-backed fallback channels for urgent escalations. A page SMS carries a four-digit code; reply with it to acknowledge (see Acknowledge by SMS reply). On a call, press 1 to acknowledge.

Acknowledge by SMS reply

A page SMS ends with "Reply 4821 to acknowledge" and a link to the alert. Each alert you are paged about gets its own code, so with several open pages each reply acknowledges exactly one. Replying acknowledges the alert in your name, the same as pressing Acknowledge in the app: escalation stops and the alert timeline records the acknowledgement.

Moneat accepts these replies:

Moneat answers each reply with a short confirmation, or says why nothing changed: someone already acknowledged the alert, it is resolved, the code expired, or no page sent to your number has that code. A code works only from the number the page was sent to, for as long as you are a member of the organization and that number is still on your profile. Codes expire 24 hours after the latest page that carried them. After five unrecognized codes in 15 minutes, the number is refused for the rest of that window. A number that was never sent a page gets no answer.

To receive replies, the Twilio number in TWILIO_FROM_NUMBER needs its incoming-message webhook set. In the Twilio Console, open the number, and under Messaging set A message comes in to Webhook, HTTP POST, at:

<BACKEND_URL>/v1/webhooks/twilio/inbound-sms

Moneat checks every request's X-Twilio-Signature with TWILIO_AUTH_TOKEN and refuses any it cannot verify. The signature covers the exact URL, so the webhook must use the same scheme, host and path as BACKEND_URL.

Configure paging

Paging shows the organization's notification policy and each responder's channel preferences. Policies are configured per urgency. The page also exposes the delivery ladder, continuation behavior, and compliance gaps.

A critical push test confirms provider acceptance, not that a physical phone sound was heard. Use the test together with the delivery result and the responder's current channel eligibility.

Read reliability

Reliability combines three views:

• Reachability — whether an urgent page would reach the responder each schedule calls. This view is available to authorized administrators.
• Delivery — notification delivery behavior and provider outcomes.
• Response — native incident response outcomes after the page arrives.

Reachability judges each responder the way a page is sent. With a saved notification order, the responder is reachable when any step the organization's policy allows can carry a page. Without one, the page follows their urgent channel preferences: a registered push device or a linked Slack account reaches them, and so does the text-and-call fallback once they have added a phone number, agreed to on-call calls, and the instance can send them. A schedule paged by an escalation step whose SMS/Call fallback delay is 0 gets no fallback, so its responders need push or Slack.

Each schedule shows two answers:

• Right now — the responder the schedule would page at this moment, including overrides and layers.
• Next shift — each handover in the next 24 hours, judged for the responder it brings on. The column names the first handover whose responder cannot be reached and what is missing, or else the next handover.

Owners and admins receive an email before a shift starts when an urgent page would not reach its responder, so there is time to fix the setup or arrange cover. Each shift is warned about once, and a responder on the same schedule at most once a day. The email names the responder and what is missing, never a phone number or a device.

They also receive an email when an alert reaches an escalation level with nobody to page and moves straight on, at most once a day per level. It names the level, its policy and what came up empty. An admin who may not read the alert, because it belongs to a private incident, gets the email without the alert.

The older product routes /on-call/readiness, /on-call/paging-reliability, and /on-call/response-outcomes redirect to the corresponding view on the Reliability page. Reliability and metric reads use a maximum 31-day window.

Verify a page

For a real test, send an alert that matches one enabled Alert Route, then inspect:

1. The matched route revision
2. The grouping decision
3. The escalation policy and target
4. Each delivery attempt and provider result
5. The acknowledgement and response outcome

If no person is paged, use the independent route and delivery checks in Troubleshooting. A received alert is not proof that a notification was delivered, and provider acceptance is not proof that a person heard a phone call.