On-call rotation

A preview of how this template lays out — the boards, their custom workflow states, and where the sample issues land. WIP caps show a badge.

• Pager: elevated 5xx on the API gateway

  • pager
  P02pt

• Customer report: stuck Slack notification

  P21pt

• Weekly on-call handoff notes

  Recurring; summarizes interrupts for the next on-call.

  P31pt

These rules aren't created when you apply the template — they're recipes you can wire up in Settings → Automations once your board exists.

• When

  Issue created with label 'pager'

  Then

  Assign to the current on-call and move to 'Inbox' top

• When

  Friday 4pm

  Then

  Generate the weekly handoff note pre-filled with open items

Handoff is a column, and that is the whole argument. On-call fails at shift boundaries far more often than it fails during a page: the outgoing engineer knows which alert has been flapping all week and which customer is already annoyed, and none of that survives a Slack message that says 'quiet week, good luck'. The Working cap of two is the second opinion — on-call is interrupt work, and an on-call engineer holding five open threads is not responding to anything, they are queueing.

1. 1.Acknowledge fast, and let Acknowledged mean only that

   Moving a card from Inbox to Acknowledged is a claim that a human has read it and owns it — not that work has started. Keeping those two things separate is what lets you see the difference between 'nobody is looking at this' and 'someone is on it', which are very different failures. An Inbox that grows during a shift is the signal that the rotation is understaffed for its alert volume.

2. 2.Log every interrupt, including the five-minute ones

   The small ones are the point. A shift that handled two pages and nineteen quick questions looks like a quiet shift in every system except this board, and the nineteen are what makes on-call exhausting. Card them all, even retroactively at the end of the day. Without that record, the argument for fixing the noisy alert or writing the missing runbook has no evidence behind it.

3. 3.Hold Working at two and escalate rather than stack

   The cap is deliberately tighter than a normal board's because the third concurrent interrupt is where quality collapses. When a third real thing lands, the correct move is to pull in a second responder or to explicitly deprioritise one, out loud, in the incident channel. A silent third item is how the second one gets forgotten.

4. 4.Make the handoff a conversation, not a document

   The Friday note is a prompt for a ten-minute live handover, not a substitute for one. Walk the incoming engineer through what is still open, what you suspect but did not chase, and which alert you have started ignoring and why. That last item is the most valuable and the least likely to be written down.

5. 5.Convert recurring interrupts into real backlog work

   Resolved is not the end of the loop. Anything that paged twice in a rotation should leave behind a linked issue on the owning team's board — a fix, a runbook, or a threshold change. On-call that never generates follow-up work is a team absorbing the same failure indefinitely, and the rotation slowly becomes the least popular job on the team.

This board encodes one opinion about how the work should run. Here is where that opinion is wrong and something else fits better.

• You do not have a paging tool. This board is the work-tracking half of on-call; it does not page anyone, does not know who is on shift, and will not wake somebody at 3am. Alerting, escalation policies and schedule management are a separate product category and you need one before a board is useful.
• You run follow-the-sun across regions with formal escalation tiers. Multi-region rotations with tier-one and tier-two handoffs need schedule-aware routing that knows who is awake, and a board cannot express that. The handoff column assumes one shift hands to one other shift.
• On-call is one person indefinitely. If the same engineer is always on-call, there is no rotation and no handoff, and the board's two most distinctive columns do nothing. The problem to solve there is staffing, not tooling.
• You need on-call compensation or fairness reporting. Paying a stipend, tracking who took the worst weeks, or proving rotation load is distributed evenly requires hours and shift data this board does not hold. Take that from the scheduling tool.

Honest comparisons, including where the other tool wins. Planoda is pre-launch, so nothing below is a benchmark — it is a description of how each product approaches this job.

• PagerDuty and Opsgenie

  These own the half of on-call this board does not: schedules, escalation policies, overrides, mobile paging, and alert routing from every monitoring source you have. They also produce the operational reports — pages per rotation, time to acknowledge, after-hours load — that make an understaffed rotation arguable rather than anecdotal.

  Where PagerDuty and Opsgenie is better: Everything about actually being paged is better there, and it is not a comparison so much as a division of labour. If you have a rotation at all you need one of these tools, and this board is what sits next to it to hold the work the pages generate.

• Jira Service Management

  Atlassian bundles on-call scheduling, alerting and a request queue into one product, so the ticket a page generates lives beside the schedule that routed it. That integration is genuinely useful, and it is a reasonable single-vendor answer for a team already inside the Atlassian estate.

  Where Jira Service Management is better: Having the alert, the schedule and the resulting ticket in one system removes the reconciliation this board asks you to do by hand. For teams that already run Jira, the marginal cost of adding it is close to zero.

• Linear

  Linear has no on-call concept, so teams there typically route pager-generated issues into Triage and rely on the normal issue workflow. That is a perfectly workable arrangement and it keeps interrupt work in the same place as planned work, which has its own advantages for visibility.

  Where Linear is better: If your priority is that interrupt work sits in the same backlog as planned work — so a manager sees at a glance that a team spent half a cycle on pages — a single unified issue list beats a separate on-call board. The separation this template creates has a real cost.