Skip to content
DevOps AI ToolKit
Newsletter
All guides
AI for Incident Response By James Joyner IV · · 9 min read

AI-Assisted On-Call Handoffs That Don't Drop Context

Most on-call handoffs lose half the context the moment the shift changes. Here's how to use AI to write a brief the next person can actually act on.

  • #incident-response
  • #on-call
  • #ai
  • #handoff
  • #sre

The most expensive five minutes in on-call isn’t a page — it’s the handoff that didn’t happen. I’ve inherited shifts where the only briefing was “quiet night, good luck,” and then watched a flaky service that had been degrading for six hours finally tip over at 09:30, in my lap, with no context about the three half-finished mitigations the previous engineer had been juggling. The information existed. It just never made the jump from one brain to the next.

Handoffs fail because writing a good one is real work at exactly the moment you’re most tired and most eager to log off. This is a perfect spot for AI to help — not by deciding anything, but by turning a noisy shift into a clean brief.

What a good handoff actually contains

Before automating anything, get clear on what you’re trying to produce. A handoff brief that’s worth reading has:

  • Open incidents and their current state (mitigated? root-caused? still bleeding?).
  • Degraded-but-not-paging conditions — the stuff that’s yellow, not red. This is where most dropped context lives.
  • In-flight changes — deploys, migrations, feature flags flipped mid-shift.
  • Suppressed or snoozed alerts and when they un-snooze.
  • Things to watch — “if checkout latency creeps past 400ms again, the fix is to restart the pool, runbook here.”

Notice that none of this requires judgment about what to do. It’s a faithful inventory of state. That’s the part AI does well and humans do tiredly.

Feeding the shift into a draft

At end of shift, I point an assistant at the raw material: my alert history for the window, the incident channels I touched, and any notes I jotted. The prompt is roughly: “Summarize this shift into an on-call handoff brief using these sections: open incidents, degraded conditions, in-flight changes, snoozed alerts with un-snooze times, watch items. Quote alert names and timestamps exactly. Flag anything ambiguous rather than guessing.”

The output is never ship-ready, and that’s fine. It’s a strong first draft that catches the things I’d have forgotten — the alert I snoozed at 03:00 and would absolutely not have remembered to mention.

Pro Tip: Ask the model to explicitly list a “snoozed/suppressed alerts” section even if it thinks there are none. Forgotten snoozes are the single most common cause of “why didn’t this page anyone?” incidents, and a model scanning your alert history will catch the 03:00 snooze your sleep-deprived brain dropped.

The judgment stays with you

Here’s the boundary I hold firmly: the AI can describe the state of the world, but it does not get to assess severity, decide what’s urgent, or tell the next person what to prioritize. Those are calls that depend on context the model doesn’t have — the customer who’s already escalated to your VP, the release that ships at noon, the fact that the “minor” degraded service feeds the billing pipeline.

So when I review the draft, I add the judgment layer myself. I reorder by what actually matters. I add the “watch this one closely” notes that come from instinct. The model gives me a complete inventory; I supply the priorities. That division is the whole point — AI for synthesis, humans for decisions.

Real-time handoffs during a live incident

Mid-incident handoffs are even higher-stakes, because you’re transferring an active mental model under time pressure. The pattern that works: keep a running incident summary that you refresh every 20–30 minutes (this pairs well with summarizing the incident channel into a few bullets), so that at any moment there’s a current-state snapshot the incoming person can read in 60 seconds.

The handoff then becomes: incoming engineer reads the latest snapshot, outgoing engineer does a two-minute verbal confirmation of what’s not in the snapshot (the gut feel, the thing they were about to try). The AI handles the boring continuity; the humans handle the transfer of intent.

Making it a habit, not a hero act

The reason handoffs degrade is that they depend on the discipline of a tired person. Lower the activation energy. Keep a standard handoff prompt in your prompt workspace so every engineer generates the same shape of brief, and the incoming person knows exactly where to look for snoozed alerts or in-flight deploys. Consistency is its own form of reliability.

If you’re using a terminal-centric workflow, something like Warp can pull command history and shape it into notes, and a general assistant like Claude is plenty for the summarization itself. The tool matters less than the ritual.

What I won’t automate

I won’t let the AI send the handoff and consider the job done, and I won’t let it decide a shift was “quiet” on my behalf. A handoff is a human accepting responsibility from another human. The brief is just the artifact that makes the transfer honest. AI makes that artifact complete and consistent in a fraction of the time — which means it actually gets written, which is more than I can say for most “quiet night, good luck” shifts.

For more on building a rotation where handoffs like this are the norm, the incident-response category has companion pieces on on-call health and escalation. And if you want reusable framings, the prompt library is a good place to start.

Free download · 368-page PDF

Download the Free 500-Prompt DevOps AI Toolkit

500 battle-tested, copy-paste AI prompts engineered by a senior systems engineer — every one with fill-in placeholders and safety/back-out notes. Drop your email and it's yours.

  • 500 prompts: Linux · Kubernetes · Terraform · OpenStack · GitLab · Docker · Monitoring · Incident Response
  • Instant PDF download — yours free, forever
  • Plus one practical AI-workflow email a week (no spam)

Single opt-in · unsubscribe anytime · no spam.