# Async on-call handoff template (copy-paste for Slack, Notion, or Google Docs) *August 11, 2026* > **TL;DR:** A structured on-call handoff captures active incidents, recent deploys, known workarounds, runbook links, pending follow-ups, and current system state so context survives the shift boundary. Below you'll find copy-paste templates for Slack, Notion, and Google Docs. Write the handoff async by default and reserve a live call for an open P0 or P1. Budget 10 to 15 minutes to write it and 20 to 30 minutes of total overlap, so the incoming engineer can read it, ask questions, and explicitly accept the pager. Inheriting a pager with zero handoff notes and then getting paged by an alert the previous engineer already debugged is a common pain point. A structured async handoff stops this from happening. The evidence for structure is strongest outside software: when nine pediatric residency programs adopted a standardized handoff protocol, [medical errors fell 23%](https://www.nejm.org/doi/full/10.1056/NEJMsa1405556) and preventable adverse events fell 30%. Shift boundaries are where this bites hardest. Once your shift ends you stop being paged, because incident.io only considers you on call while you are [currently active on a schedule](https://docs.incident.io/on-call/determining-on-call). An alert the outgoing engineer never acknowledged does not stay with them, so it lands on whoever the escalation path reaches next, usually the person with the least context on it. The templates below give you that structure, ready to drop into whatever tool your team already uses. ## Copy-paste templates by platform The three templates below are ready to use as-is. Pick the one that matches your team's primary documentation tool. ### Slack handoff message template Paste this into your `#on-call-handoff` channel at the end of every shift. ```text *🔁 ON-CALL HANDOFF | [DATE] [OUTGOING TZ]* *Outgoing:* @yourname | *Incoming:* @theirname *Shift:* [START DATE/TIME] → [END DATE/TIME] --- *ACTIVE INCIDENTS* • [P0/P1/P2/P3] *[Incident name]* | [incident.io channel link] Status: [Investigating / Fixing / Monitoring] Last update: [Timestamp + one-line summary] Next action: [What the incoming engineer needs to do first] • None: system stable at handoff ✅ --- *RECENT DEPLOYMENTS (last 24h)* • [Service name] @ [version/commit] | deployed [time] by [team] Watch for: [Any known risk or metric to monitor] • No deploys in the last 24 hours ✅ --- *KNOWN ISSUES & ACTIVE WORKAROUNDS* • [Service/alert name]: [Description of flaky behavior + workaround in place] Ticket: [Jira/Linear link] | ETA for fix: [Date or "unknown"] • None ✅ --- *RUNBOOKS & ESCALATION PATHS* • [Service A] runbook: [link] • Escalation: [Name/team] | [contact method] | [when to page them] --- *PENDING FOLLOW-UPS* • [ ] [Task description] | owner: [Name] | due: [Date] • [ ] [Task description] | owner: [Name] | due: [Date] --- *SYSTEM STATE SUMMARY* [2-3 sentences: overall system health, anything to watch, and one sentence confirming the incoming engineer has read this and is clear to take the pager] ``` Keep the system state summary last, and keep it human. Scribe transcribes incident calls and captures decisions in real time, and Investigations surfaces likely root causes from telemetry and code changes, so much of the incident detail above can be lifted straight from what the platform already recorded. Confirm the overall system state yourself before you hand over the pager. ### Notion handoff page template Set this up as a Notion database with a template button so any engineer can click once and generate a fresh handoff page without remembering which page to duplicate. **Suggested database properties:** * Date (date picker, auto-fills to today) * Outgoing engineer (person property) * Incoming engineer (person property) * Shift status (select property: Active, Handed off, Archived) * P0/P1 active (checkbox property) **Page body structure:** ```text # On-call handoff | [DATE] ## 📌 Roles | Role | Engineer | |---|---| | Outgoing | [Name] | | Incoming | [Name] | | Backup | [Name] | ## 🔴 Active incidents | Severity | Name | Channel | Status | Next action | |---|---|---|---|---| | P1 | [Name] | [Link] | Monitoring | [What to do] | ## 🚀 Recent deployments | Service | Version | Time | Team | Watch for | |---|---|---|---|---| | [Service] | [SHA] | [Time] | [Team] | [Risk] | ## ⚠️ Known issues & workarounds - **[Alert name]:** [Description]. Workaround: [Steps]. Ticket: [Link]. ## 📖 Runbooks & escalation - [Service A] runbook: [link] - Escalation contact: [Name, method, when to use] ## ✅ Pending follow-ups - [ ] [Task] | [Owner] | due [Date] ## 🟢 System state [2-3 sentence summary of overall health. Incoming engineer confirms they have read this section before accepting the pager.] ``` incident.io's Catalog maps your services to their owners and escalation paths, so the escalation section of your handoff comes from a single source of truth rather than tribal knowledge. Our [automated runbook guide](https://incident.io/blog/automated-runbook-guide) covers how to connect integrations. ### Google Docs handoff template For teams that keep documentation in Google Drive, use a tabular layout engineers can scan quickly. Copy this structure into a new Doc, save it to your team's shared drive, and link it from your on-call runbook. ```text ON-CALL HANDOFF | [DATE] | Outgoing: [Name] | Incoming: [Name] ACTIVE INCIDENTS Severity | Name | Link | Status | Next Action P1 | ... | ... | ... | ... RECENT DEPLOYMENTS (last 24h) Service | Version | Time | Team | Risk ... KNOWN ISSUES Alert/Service | Issue | Workaround | Ticket | ETA ... RUNBOOKS Service | Runbook URL | Notes ... PENDING FOLLOW-UPS Task | Owner | Due Date | Done? ... SYSTEM STATE [Write 2-3 sentences here. Incoming engineer signs off below.] Incoming engineer confirmed: [Name] at [Timestamp] ``` ## What to include in every handoff Every handoff should cover six core areas, regardless of platform. Missing any one of them leaves the incoming engineer without the context they need to make safe decisions at the start of their shift. ### Active incidents and their status Document every open incident with severity in incident.io's P-notation (P0, P1, P2, or P3), the incident.io channel link, current status, last meaningful update, and the single most important action for the incoming engineer to take first. List multiple open incidents in severity order. Use [incident.io's status update workflow](https://docs.incident.io/incidents/status-updates) to confirm that the platform's timeline matches what you write: the two should agree. For an incident that is still live at the shift boundary, transfer the roles inside the incident itself as well as in the written note. The [/inc handover command](https://docs.incident.io/incidents/shortcuts) hands over responsibilities in the incident channel, so the record of who owns what stays accurate without anyone updating it by hand. ### Recent changes and deployments List every deploy, configuration change, and feature flag toggle from the last 24 hours (or the full shift for shorter rotations). Include the service, version or commit SHA, deploy time, and what metric or behavior to watch for as a result. Rank them by blast radius rather than by time. A config change to a shared authentication service matters more to the incoming engineer than three routine deploys to an internal admin tool, even if the deploys are more recent. ### Known issues and workarounds Document anything that is alerting but that you are not actively fixing, including deliberately silenced alerts. If you silenced an alert, say so explicitly with the reason and the expected silence window. The incoming engineer needs to know which alerts are noise today and which ones warrant immediate investigation. The [incident.io on-call best practices guide](https://incident.io/blog/on-call-best-practices-guide-2026) covers this pattern in depth. ### Runbook and escalation links Paste direct links, not just service names. Every on-call engineer should be able to click a link in the handoff and land on the exact runbook page in seconds. Include the escalation path: who to contact for each major service, how to reach them (Slack DM, phone, pager), and the threshold that triggers escalation. Connect your runbooks and reference docs to incident.io and it indexes them for keyword and semantic search, so [relevant runbooks surface as evidence](https://docs.incident.io/nexus/documentation) inside an investigation. Anyone can also ask the agent a question during an incident and get an answer that cites the specific doc it drew on, with a link back to the source. ### Pending follow-ups and action items Follow-up action items are easy to lose once the incident is resolved and the channel goes quiet. Ownership becomes unclear, and time-sensitive tasks slip. List every open action item with a clear owner and due date. If ownership is unclear, document that explicitly so the incoming engineer knows which items need escalation decisions. incident.io's post-mortem workflow captures the full timeline automatically, as shown in the [post-mortems product showcase](https://youtube.com/watch?v=TKYyT3FfgJk). If your follow-ups live in Linear, [follow-up action tracking with Linear](https://youtube.com/watch?v=vHJNVANtYyI) shows how the timeline connection cuts the reconstruction burden at handoff time. ### System state and pager acceptance The last block is the easiest one to skip, and it is the one that makes the handoff binding. Write 2 to 3 sentences on overall system health, name anything the incoming engineer should watch, then have them confirm in writing that they have read the note and are taking the pager. That explicit confirmation is not ceremony. Google's SRE Book makes the same point about handing over incident command: the outgoing commander should state the handoff plainly and wait for [firm acknowledgment of handoff](https://sre.google/sre-book/managing-incidents/) before stepping away. A handoff nobody acknowledged is a handoff that did not happen, and the gap only becomes visible when the next page fires and neither engineer thinks they own it. **Handoff timing checklist:** | Phase | Suggested time | What happens | | --- | --- | --- | | Written prep | 10-15 minutes | Outgoing engineer drafts the handoff note | | Sync / review | 10-15 minutes | Incoming engineer reads, asks questions | | Total overlap | 20-30 minutes | Pager transfer complete | ## Where to host the template so it gets used A template nobody can find is useless. The hosting decision matters as much as the template itself. ### Pinned message in your on-call channel Pin the most recent handoff to a dedicated `#on-call-handoff` Slack channel so every incoming engineer checks there first. Use Slack [notifications for schedule changes](https://docs.incident.io/on-call/slack-schedule-notifications) to announce the change of hands in that channel automatically. ### Saved Slack workflow or slash command Automate the handoff prompt so engineers don't have to remember to find the template. incident.io's custom workflows can post a prompt the moment the pager changes hands, using the [on-call schedule shift change trigger](https://docs.incident.io/on-call/slack-schedule-notifications), which can drop the previously on-call and currently on-call users straight into the message. Here's a sample payload you can wire into a Slack workflow or into incident.io's [shift change webhook](https://docs.incident.io/api-reference/shift-v1/change-public): ```json { "text": "🔁 On-call has just changed hands", "blocks": [ { "type": "section", "text": { "type": "mrkdwn", "text": "*On-call has just changed hands.*\nPlease complete your handoff in #on-call-handoff.\n\n:clipboard: <https://notion.so/your-handoff-template|Open handoff template>" } } ] } ``` You can also [sync on-call schedules automatically](https://docs.incident.io/on-call/sync-slack-groups) with Slack user groups, so the group updates at each handover to contain only whoever is on call right now. One note before you connect a group: doing so replaces all of its existing members with the synced set. ### Bookmarked Notion template In Notion, create a template button on your on-call database so any engineer can click once, generate a pre-populated handoff page with today's date and their name, and fill in the six sections without touching any formatting. ### Runbook or wiki link Embed the handoff template link in step one of your on-call onboarding runbook. When a new engineer goes through their first on-call orientation, they see the template before they ever carry the pager. ## How to adapt the template for your team The templates above are intentionally generic. Layer in context specific to your stack within the first week of using them. ### Add service-specific context sections A database-heavy team should add a "Database health" section with links to RDS or CloudSQL dashboards, replication lag thresholds, and the DBA escalation path. A frontend-focused team should add a "CDN and edge cache" section with links to Cloudflare or Fastly dashboards. Microservices teams should add a "Service dependency map" link so the incoming engineer can quickly assess blast radius during an active incident. ### Link to your monitoring dashboards Paste pre-filtered Datadog, Prometheus, or Grafana dashboard URLs directly into the handoff template, scoped to the last 24 hours and to the services your team owns. The incoming engineer should click one link and see the current system state without navigating the dashboard UI from scratch. The [Slack for incident management guide](https://youtube.com/watch?v=D7kVme18RVQ) covers how to embed monitoring context directly into Slack-based incident workflows. ## Common handoff mistakes to avoid These three mistakes are worth checking against your current process. ### Skipping handoff when "nothing happened" A quiet shift still requires a handoff, because the incoming engineer needs confirmation that the shift was actually quiet, not that you forgot to document it. Write a zero-incident handoff that explicitly confirms: system stable, no deploys in last 24 hours, no silenced alerts, no pending follow-ups. ### Burying critical info in paragraphs The incoming engineer reads your handoff at the end of a Friday afternoon, or at 5 AM after being woken by a page. They don't read prose. Every critical piece of information (severity, service name, runbook link, next action) belongs in a labeled field, not buried in a paragraph. The [how to automate incident postmortems](https://youtube.com/watch?v=E53e-3RTU80) guide applies the same principle to post-mortem documentation: structure before prose, always. ### Using a different format each time Format inconsistency [multiplies cognitive load](https://www.nngroup.com/articles/consistency-and-standards/). When the incoming engineer can't predict where the "Active incidents" section will be, they slow down scanning and risk missing something. If an engineer skips sections or reformats the template, treat it as a blameless post-mortem action item to improve the template rather than a personal failure. > "The automated incident lifecycle is the standout. The moment an alert fires, a dedicated Slack channel spins up with severity, incident manager, and reporter already assigned, and the status timeline ... updates itself as the team works the problem. Post-mortems and follow-up tracking are built into the same flow." - [Luca G. on G2](https://g2.com/products/incident-io/reviews/incident-io-review-13168828) incident.io's custom workflows enforce that consistency automatically. [Fin migrated off PagerDuty and Atlassian Status Page](https://incident.io/customers/fin) to incident.io and reports faster MTTR alongside lower cognitive load, driven by AI-generated incident summaries and real-time highlights. ## Making the handoff stick A template fixes the format problem. It does not fix the reconstruction problem: someone still has to assemble the incident detail, the deploy list, and the timeline by hand, at the exact moment they most want to log off. That's the gap incident.io closes. PagerDuty's alert routing is more mature and deeply customizable, and we integrate with it rather than replace it. Our edge is coordination: the entire incident lifecycle, from shift-change prompt to timeline capture to post-mortem draft, runs inside Slack on a transparent [Pro plan at $45/user/month with on-call](https://incident.io/blog/incident-io-pricing-breakdown) ($25 base plus $20 on-call add-on). If you're still on Opsgenie, that migration is already on your calendar: Atlassian ends support on [April 5, 2027](https://www.adaptavist.com/blog/atlassian-opsgenie-availability-changes-effective-june-4-2025). Our [Opsgenie migration guide](https://incident.io/blog/how-to-migrate-opsgenie-playbook) covers the parallel-run strategy, so handoff continuity survives the cutover. You can also watch the on-demand session on [migrating from PagerDuty](https://youtube.com/watch?v=P7UZAnBTa9g) to see how teams codify these workflows during a transition. Start with the template that matches your stack and run it for two weeks. When you're ready to close that gap, [book a demo of incident.io](https://incident.io/demo) and see how much of your next on-call handoff incident.io can fill in for you. ## Key terms glossary **MTTR:** Mean Time To Resolution, the average time from incident detection to full resolution. **P0/P1/P2/P3:** Common severity tiers for incidents, ranging from P0 (highest severity) to P3 (lowest). These templates use P-notation for broad compatibility, though severity systems vary by platform. **SRE:** Site Reliability Engineering, the discipline of building and operating reliable systems at scale. SRE teams typically own on-call rotations, incident response, and post-mortem processes. **DBA:** Database Administrator, the role responsible for database configuration, performance, and uptime. The DBA escalation path should be documented in handoff templates for database-heavy teams. **CDN:** Content Delivery Network, a geographically distributed network of servers that cache and serve static content to reduce latency. Frontend teams should include CDN health checks in handoff templates. **SHA:** Secure Hash Algorithm, commonly used to identify specific code commits in version control systems like Git. Include the commit SHA in deployment records so incoming engineers can trace changes. **Scribe:** incident.io's AI call transcription feature, which captures decisions and key moments from incident calls in real time without requiring a dedicated note-taker. **Investigations:** incident.io's product for analyzing telemetry, code changes, and past incidents to surface root causes. Automates up to 80% of incident response. **Runbook:** A documented set of steps for diagnosing and resolving a specific alert or incident type. Every runbook link in a handoff should point to the exact page, not a wiki root.