What this template is for
On-call handoff is the moment of greatest information loss in any SRE team. The outgoing on-call has a week of context in their head; the incoming on-call has none of it. Without a structured handoff, that context gets compressed into a 90-second slack message and most of it is lost.
This template forces the outgoing on-call to write down what they know - which alerts are noisy, which incidents are still warm, what they deferred and why - so the next shift starts with the same context, not an empty pager.
When to use it
Use this template at every rotation boundary - weekly for most SRE teams, daily for follow-the-sun rotations. Use it even if no incidents happened during the shift; the absence of incidents is itself useful context for the next person.
How to set it up in Jira
Create an On-Call Handoff issue type with the fields above on its Create Issue screen. Use STM Issue Templates with a scheduled Executor (or an On Create Issue Executor fired by your rotation tool’s Jira integration) to lay down the standard sub-task checklist every time a new handoff ticket appears. The handoff ticket should be linked to the rotation’s parent epic so a full shift history is one query away.
Fields to add to your Jira create screen
These are the fields a project admin should make sure exist on the Create Issue screen for this issue type (Project settings → Screens). Without these on the screen, reporters can't provide the information triage needs - and STM can't reference them either.
| Field | Example value | Required |
|---|---|---|
Summary | On-call handoff - payments rotation - 2026-05-23 09:00 UTC | Yes |
Outgoing On-Call (custom) | @alex.chen | Yes |
Incoming On-Call (custom) | @priya.patel | Yes |
Rotation (custom) | payments-primary | Yes |
Shift Window (custom) | 2026-05-16 09:00 UTC - 2026-05-23 09:00 UTC | Yes |
Active Alerts (custom) | 1 firing: payments-svc p99 latency > 800ms | Yes |
In-Flight Incidents (custom) | INC-1421 - SEV3 - awaiting vendor | Yes |
Deferred Tickets (custom) | PROJ-1390, PROJ-1402 | No |
Watch-Outs (custom) | DB primary failover scheduled 2026-05-24 | No |
Runbook Changes (custom) | RB-118 updated to add new error code | No |
Linked Postmortems | PROJ-1380 - SEV2 from 2026-05-19 | No |
Note on custom fields. STM currently supports up to 5 custom fields per template. You can add as many custom fields as you like to your Jira Create Issue screen - the 5-field limit only applies if you want STM to set or update those custom fields itself.
Sub-tasks STM creates automatically
Build an STM sub-task template containing the items below, then wire it to an On Create Issue Executor scoped to this issue type. Whenever a new issue of this type is created in the project, STM creates the full sub-task set in one step - with assignee, due date, and components inherited from the parent unless you override them.
- Outgoing: list all firing and recently-resolved alerts with notes
- Outgoing: summarise in-flight incidents and current state
- Outgoing: list deferred tickets and why they were deferred
- Outgoing: call out scheduled risky changes during the next shift
- Live handoff call - 15 minutes, voice not chat
- Incoming: acknowledge handoff and confirm pager rotation switched
Common questions
What is an on-call handoff in Jira used for?
It is the written record of one shift passing to the next - which alerts are firing, which incidents are open, which tickets were deferred and why, and which scheduled risks land during the incoming shift. The Jira ticket becomes searchable history so 'what happened on last week's handoff?' has a stable answer.
How long should an on-call handoff take?
Around 15 minutes of live voice, supported by a written ticket that the outgoing on-call fills in beforehand. Voice is non-negotiable because tone and context don't translate to chat - 'we think it's fine but watch the latency' reads differently than it sounds. The ticket is the artefact; the call is the handoff.
Should on-call handoff tickets be created automatically?
Yes - the handoff cadence is predictable (weekly, daily, or per-rotation), so a recurring ticket makes sense. [STM Issue Templates](/stm/) can lay down the standard sub-task checklist on every new handoff ticket so the outgoing on-call has the same prompts every time, and the artefact is consistent across rotations.
What information must be in an on-call handoff?
At minimum: active alerts, in-flight incidents, deferred tickets, watch-outs (scheduled changes that land during the next shift), and any runbook changes the outgoing on-call made. The watch-outs field is the most-skipped and most-valuable - it warns the incoming on-call about scheduled risk they would not otherwise see.
Automate the sub-tasks with STM
STM Issue Templates saves the sub-task list above as a reusable template and creates them on every new issue of this type - via an Executor on issue creation, on status transition, or triggered manually from the issue's "Create bulk sub-tasks" menu. STM does not change the parent issue's create screen (that's a Jira project-settings job) but it removes the manual work of creating the sub-tasks every time.
Try STM on the Atlassian Marketplace ↗ See how STM templates are built →