Blog Incident response

SMS and voice call paging for incidents

Email is fine for a warning. It is not how you wake someone up at 3am. For that you want a text, and if the text doesn't work, a phone call.

This post covers how ZipLogger pages people by SMS and voice call: who gets what, what the message actually says, how to acknowledge from the phone, the two ways to send it, and what it costs. The message text and timeline lines below come from ZipLogger's notification code.

Who gets paged by phone

Each person decides for themselves. On Profile → On-call paging there are three fields:

  • A phone number in international format, such as +14155550123. Anything else is refused with "Enter the phone number in international format, e.g. +14155550123."
  • Page me by SMS
  • Call me

When an escalation step, a team hand-off or a manual assignment pages someone, they always get an email. They also get an SMS if they ticked Page me by SMS, and a voice call if they ticked Call me. Clearing the phone number switches both off.

Who is paged in the first place comes from on-call teams, schedules and escalation policies. The on-call schedules post covers that setup.

There is a second, simpler route. An alert rule has its own SMS to and Call to fields that take a fixed number. That suits a shared on-call phone. It sends whenever the rule fires, whoever is on the rotation.

What the SMS and the call say

For an incident titled "checkout-api 5xx above 5%" paged through an escalation policy, the text ZipLogger sends to Twilio's Messages.json is:

[ZipLogger] checkout-api 5xx above 5% FIRING. Acknowledge the incident in ZipLogger to stop the escalation. Reply 4821 to ack.

4821 is a 4-digit code for this one page. The call goes to Twilio's Calls.json with inline TwiML. The alert is read inside a one-key <Gather>, and the key press posts back to ZipLogger:

<Response><Gather numDigits="1" timeout="8" method="POST" action="https://app.ziplogger.ai/api/v1/incidents/ack/voice?token=…"><Say>This is a Zip Logger alert. checkout-api 5xx above 5% is firing. Acknowledge the incident in ZipLogger to stop the escalation.</Say><Say>Press 1 to acknowledge.</Say></Gather><Say>Not acknowledged. Goodbye.</Say></Response>

A few things follow from that:

  • Keep incident titles short. The SMS and the spoken text are each capped at 150 characters. A long title pushes the rest off the end, but never the reply code: that goes last and is never cut.
  • The SMS has no link. The email that goes out at the same time has the incident summary, an "Open the incident in ZipLogger" link and an Acknowledge button.
  • Calls only ring for a firing incident. Nobody is called about a recovery.
  • No all-clear text for paged people. When the incident resolved in our run, the people paged by the escalation policy got nothing. The alert rule's own SMS to number does get a RESOLVED text.

Acknowledge from the phone

Every page to a person (an escalation step, a hand-off to a team, a manual assignment) carries a way to acknowledge it without signing in:

PageWhat to do
SMSReply 4821 or ack 4821. When that number has only one open page, ok or 1 also works.
Voice callPress 1 while the call is reading the alert.
EmailClick Acknowledge. It opens a page in ZipLogger that shows the incident and an Acknowledge button.

The email link does nothing until you click the button on that page. Mail scanners open every link in a message, and a scanner should not be able to acknowledge your incident.

A reply to the SMS gets an answer back:

Acknowledged: checkout-api 5xx above 5%. You own it now.

The rules are the same for all three:

  • It acts as the person who was paged. That person must still be an Editor or Admin of the workspace. The incident timeline says how it happened: "SMS reply: Alice", "Phone: Alice" or "Email link: Alice".
  • Once, for 24 hours, for that incident. A second use answers that the incident "was already acknowledged. Nothing changed." An old code cannot acknowledge a newer incident.
  • It stops the escalation, like any acknowledgement, and the delayed SMS or call for that person is dropped.
  • Recoveries carry no code. Nothing to acknowledge once it is resolved.
  • The alert rule's own SMS to and Call to numbers are not a page to a person, so they get no code.

SMS replies go through Twilio

A reply has to reach ZipLogger. If you connect your own Twilio account, set this on each number you send from, in Twilio under Phone Numbers → Messaging → "A message comes in", as a Webhook with HTTP POST:

https://app.ziplogger.ai/api/v1/notifications/twilio/sms

ZipLogger checks Twilio's signature on every request with your account's auth token, and refuses anything unsigned. The same webhook handles STOP from status page SMS subscribers.

Telnyx inbound texts are not wired up. On a Telnyx connection, use the call (pressing 1 works with Telnyx TeXML too) or the email button.

Built-in sender or your own Twilio or Telnyx

The setting is under Settings → Integrations, on the card Alert notifications (SMS, calls & email).

Built-in senderYour own Twilio or Telnyx
SetupNoneAn Admin connects the account
Who pays the carrierZipLogger, metered against your workspaceYour provider, at your rates
Metered by ZipLoggerSMS, calls and emailEmail only
From numberZipLogger'sYours

To connect Twilio, pick Twilio and enter the Account SID (the 34-character value starting with AC), the Auth Token and a From number. For Telnyx, enter the Telnyx API key, a From number and, if you want calls, a TeXML application id. Without the TeXML id a Telnyx connection sends SMS only, and the card says "SMS only".

The credentials are checked before they are saved. For Twilio, ZipLogger fetches your account. For Telnyx, it lists one phone number. Neither sends a message or costs anything. The token is encrypted at rest and never shown again. Disconnect falls back to the built-in sender.

One thing that surprises people: connecting your own provider does not make alert email free. Email always goes through ZipLogger's sender and is metered either way.

What it costs and which plans have it

SMS and voice paging need a paid plan. In the current plan catalog that is Pro, Team and Business, not Free. On a plan without it, the incident still opens, email still goes out, and the timeline records why the phone stayed quiet:

SMS notification skipped (escalation_step_1) → Quinn (+141…103): SMS and voice paging are not included in this plan. Upgrade to page by phone; webhook and email still work.

This check applies even if you connected your own Twilio. It is a plan feature, not a question of who pays the carrier.

On the built-in sender, each month includes a free allowance of SMS, calls and emails. Past that, sends draw from prepaid credits that an Admin buys on the same card. The card shows this month's usage and your balance. A send that fails is not charged. The allowance and per-message prices are on the pricing page.

Hold the phone back with a notification policy

Paging every channel at once is loud. Alerts → Delivery → Notification policies lets you say, per severity, which channels go out and after how long. The page offers a suggested starting point:

SeverityChannelDelay
criticalEmail0 min
criticalSMS5 min
criticalVoice call10 min
highEmail0 min
highSMS10 min
any severityEmail0 min

A delayed SMS or call is cancelled if someone acknowledges before it is due. So for a critical incident the on-call person gets an email, then a text five minutes later, then a call five minutes after that, unless they react first. Tick Workspace default so the policy applies to pages across the workspace. With no policy at all, every channel a person opted into goes out at once.

A policy can hold a channel back or leave it out. It can never page someone by SMS or call if they haven't opted in on their profile.

When the carrier has a bad night

Every page is a row in a delivery ledger, and every attempt shows up on the incident timeline with a masked number.

  • Retries. A failed send is retried. By default that is three attempts in total, one minute and then five minutes apart.
  • No retry after acknowledgement. If the incident was acknowledged in the meantime, a failed SMS or call is dropped rather than retried.
  • Flood control. By default one phone number gets at most three SMS (and separately three calls) in ten minutes. The fourth incident in a row produced this line instead of another text:
SMS notification not sent (escalation_step_1) → Pat (+141…102): already paged 3 times in the last 10 minutes (flood control).
  • No double charge. A retried send is metered under the same key, so one recipient is never charged twice for one page.

A message that was already handed to Twilio or Telnyx cannot be recalled. If someone acknowledges while the last SMS is in flight, it may still arrive.

Next step

Add your number under Profile → On-call paging, then open Alerts → On-call → Teams and press Who is on call? to check you are the one who will be paged. The alerts docs list every notification channel. If you don't have a workspace yet, start free. Phone paging needs one of the paid plans on the pricing page.

Microsoft Teams incident alerts with actions

Get ZipLogger incident cards in a Teams channel or chat, and acknowledge, assign or resolve them from the card. Setup, account linking and limits.

On-call schedules and escalation policies

Set up on-call teams, rotations with primary and secondary layers, overrides, a repeating escalation policy, calendar subscriptions and postmortems in ZipLogger.

Slack incident alerts you can acknowledge

Post ZipLogger incidents to a Slack channel as one message that updates in place, with Acknowledge, Assign to me and Resolve buttons that act as the person who clicked.

Try it on your own logs

There is a free plan and no sales call. Install an SDK, send a few log lines, and search them.