There's a strange ritual in our industry. A team sets up monitoring in one product, then signs up for a second product whose only job is to decide which human the first product should wake up — and connects the two with a webhook that nobody monitors.
That glue is where pages go to die. The webhook silently breaks after an API key rotation, the user lists drift apart, and the billing is per-seat on both sides. All of it exists because historically, monitoring tools stopped at "send an email to the team" and paging tools started at "who's on rotation."
WatchFor takes a different position: on-call is part of monitoring, not a product next to it. This post walks through what that looks like in practice — and, because "we have on-call" can mean anything from a shared inbox to a full scheduling engine, it's specific about the mechanics.
The four pieces of real on-call
A serious on-call system needs four things working together:
- A schedule — who owns incidents at any given moment, computed from a rotation, not a spreadsheet.
- Escalation — what happens when that person doesn't respond.
- Personal paging — how the page reaches them, not a shared channel everyone has muted.
- Accountability — a record of who was on call, who was paged, and for how long — because someone has to approve the compensation.
Miss any one of them and you have a toy. Let's take them in order.
1. Rotations that match how teams actually work
A WatchFor schedule is a set of layers, each with participants in rotation order, a handoff time, and a cadence — daily, weekly, or every N days — evaluated in the schedule's own timezone (DST included, because a 09:00 handoff should stay 09:00 in March).
The patterns teams actually use are one click each: weekly, every two weeks, monthly, or weekdays/weekends split — that last one builds two layers with day-of-week restrictions automatically, so one pair of people covers business days and another covers weekends without a second schedule.
Two design choices matter more than they look:
- A live preview in the editor. As you change participants, cadence or the anchor date, a four-week calendar redraws immediately. You see every handoff before saving — not after the wrong person got paged on Saturday.
- A month calendar, not just "who's up next". The whole rotation is visible as a color-per-person calendar, week or month view, navigable into the past and future.
2. Escalation chains that stop when a human responds
An escalation policy is a ladder: Level 1 pages whoever the schedule resolves at that moment. If nobody acknowledges within the wait time you set, Level 2 fires — a backup engineer, a manager, or a shared channel. Then Level 3, and optionally the whole chain repeats.
The rules around the ladder are where trust is won or lost:
- Only confirmed critical incidents start a chain. A failure has to be verified from multiple probe locations first, and warnings never page. If the page fired, it's real.
- Acknowledge stops everything, instantly. Ack the incident — from the dashboard or wherever you saw it — and the remaining levels never fire. Resolving stops it too. This is the same convention PagerDuty and Opsgenie trained the industry on, and it's the right one.
- Silences and maintenance windows are respected. A monitor in a scheduled maintenance window doesn't page the chain at 03:00 about downtime you planned at 14:00.
- The chain survives restarts. Escalation state is stored, not held in a process's memory — a deploy mid-incident doesn't lose your place on the ladder.
Attaching a policy is deliberately simple: point it at a notification group, and every monitor that routes alerts through that group escalates criticals through it. Team channels still get every notification in parallel — escalation adds a guarantee that someone specific responds; it never takes the team's visibility away.
3. Personal paging — six ways to reach a human
Escalations page people through their own notification methods, configured by each person: email, Telegram, ntfy, Pushover, Gotify or Pushbullet. Push-first options matter here — Pushover and ntfy exist precisely because a page needs to cut through a muted phone in a way a group Slack message never will.
The system is honest about gaps: a rotation participant who hasn't set up any personal method is flagged with a warning right in the schedule editor — you find out at planning time, not at 03:00.
4. The unglamorous parts that make it fair
Overrides without ambiguity
Vacations and swaps are one click: click the shift on the calendar, pick who covers it, done. The details are where most tools get sloppy:
- Overlapping overrides are rejected — two overrides fighting for the same hours would make "who's on call" ambiguous, so the second one is refused until you adjust the first.
- Covering a running shift can start "from now" or be backdated to the shift's start with one click, so elapsed hours transfer too.
- Past overrides are allowed — if a swap happened but nobody logged it, you can correct the record afterwards, and the totals follow.
Replacing a person without reshuffling everyone
When someone leaves the team, editing the participant list naively re-phases the whole rotation — suddenly everyone's future shifts move. WatchFor's replace operation swaps one person into another's exact slot: nobody else's turn changes, and the transition can wait until the current shift ends.
Shift math your finance team will accept
The month view sums, per person: time on call, share of the period, and shift count — with override time itemized separately. One rule does the heavy lifting: a shift belongs to the period its handoff ends in. A week ending on the 1st counts toward the new month, not the old one, so month-boundary weeks never get split or double-counted. If you pay an on-call allowance per shift or per hour, the number you need is just there.
An audit trail for everything
Every page, override, replacement and schedule change lands in the organization's activity log with names and timestamps — and every escalation records exactly who was paged, through which method, visible on the incident timeline and in notification history.
Seeing the whole path before it fires
The piece that ties it together is the notification flow view: for any notification group, one diagram shows the complete journey of an incident — which channels fire immediately, where the escalation chain begins, each level with its wait time, who is on call right now, until when, and who takes over next.
It answers the question every new team member asks — "if this breaks at 2am, what actually happens?" — with a picture instead of tribal knowledge.
What this replaces
For a team of five paying per-seat for a dedicated paging product, on-call is often the second-largest line item after the monitoring itself — for a tool whose data all comes from the first one. Building it into monitoring removes the bill, the user-list drift and the webhook bridge in one move, and adds things the glued-together setup never had: escalation that respects maintenance windows natively, incident acknowledgement that stops the chain without an integration, and shift totals computed from the same source of truth as the alerts.
On-call management is included in WatchFor's paid plans — schedules scale with the plan tier, and there's a full write-up in the docs. If you're currently running the two-tool setup, the on-call overview shows what folding it into monitoring looks like.