O redator de transferência de plantão: transforme uma troca de turno caótica em uma transferência de incidente clara
Porque é que este prompt importa
Vague handoffs are a well-documented driver of extended incident resolution times: the next on-call engineer re-investigates problems that were already diagnosed, misses that a 'resolved' incident still has an open root cause, or doesn't learn about a degrading system until it pages again at 3am. A five-minute handoff write-up costs far less than the hour a team loses re-discovering context that already existed in someone's head.
Para que o usamos
An on-call engineer wrapping up a 8-hour shift with three alerts, one resolved incident with a lingering root cause, and a flaky Redis layer, who has ten minutes before the next engineer logs on and needs to hand off clearly instead of firing off a rushed Slack message that leaves out half the context.
Prompt
Act as a senior site reliability engineer who writes clear, actionable on-call handoffs that the next engineer can read in under five minutes. CONTEXT: - Shift window: [START TIME/DATE] to [END TIME/DATE] - Alerts and incidents during the shift: [LIST EACH ALERT/INCIDENT WITH ROUGH TIME AND SYSTEM AFFECTED, e.g. "02:14 — payment-api p99 latency breached 2s threshold for 8 minutes"] - Actions taken and outcomes: [WHAT YOU DID FOR EACH ITEM AND WHETHER IT RESOLVED, MITIGATED, OR IS STILL OPEN] - Current system state: [ANYTHING DEGRADED, FLAKY, OR BEING WATCHED EVEN IF IT DIDN'T PAGE] - Scheduled or in-flight changes: [DEPLOYS, MIGRATIONS, OR MAINTENANCE THAT STARTED OR IS PLANNED DURING THE NEXT SHIFT] TASK: Convert these shift notes into a handoff document the next on-call engineer can act on immediately, without needing to ask follow-up questions or dig through dashboards to understand current state. CONSTRAINTS: - Do not write vague status language like "keep an eye on things" or "should be fine." Every open item needs a specific next action and, if known, an owner. - Separate items that need immediate attention from items that are informational only — do not bury a live risk among resolved items. - If an incident was resolved, state the resolution and whether a follow-up (postmortem, ticket, permanent fix) is still outstanding — "resolved" and "fully closed" are not the same thing. - If you don't have enough information to assess severity or next steps for an item, say so explicitly rather than guessing. OUTPUT FORMAT: 1. One-line TL;DR at the top — the single most important thing the next engineer needs to know before anything else 2. Still-Open Issues — table with columns: Issue | Current State | Next Action | Owner (if known) 3. Resolved During Shift — what broke, what fixed it, and whether a follow-up ticket/postmortem is still outstanding 4. Watch List for Next Shift — things that didn't page but are trending toward a problem 5. In-Flight Changes — anything deploying or migrating that could affect the next shift
Resultado
Shift: Oct 9, 22:00 – Oct 10, 06:00 UTC
TL;DR
Payment API latency spike is resolved but the root cause (a slow downstream fraud-check call) is not fixed — it will likely recur under similar load. Redis cache layer is flapping and needs attention before it causes a real outage.
Still-Open Issues
| Issue | Current State | Next Action | Owner |
|---|---|---|---|
| Redis cache-layer connection drops (3x this shift, ~90s each) | Self-recovers each time, no customer impact yet, but frequency doubled vs. last week | Check connection pool sizing and recent Redis client version bump; escalate to infra if it recurs before 10:00 | Unassigned — flagging for infra team |
| Fraud-check service p99 latency at 1.4s (up from 400ms baseline) | Caused the payment-api latency spike at 02:14; mitigated by raising payment-api's timeout, not fixed at the source | File a ticket with the fraud-check owners; current mitigation is a band-aid that will mask further degradation | Payments team (ticket not yet filed) |
Resolved During Shift
02:14 — payment-api p99 latency breach (8 min). Root cause: fraud-check service slowdown. Fix applied: raised payment-api's downstream timeout from 1s to 2s, which stopped the cascading retries. This is a mitigation, not a fix — follow-up ticket still outstanding (see Still-Open Issues above).
Watch List for Next Shift
Redis connection pool: if drops hit 4+ occurrences or exceed 90 seconds, treat as a page-worthy incident rather than a watch item. Fraud-check latency: if it crosses 2s p99, the current timeout mitigation will stop working and payment-api will start erroring instead of just slowing down.
In-Flight Changes
None scheduled for the next shift. A database index migration on the orders table was originally planned for 08:00 but has been pushed to tomorrow — confirm with the DB team before assuming it's still off.
Toda rotação de plantão tem o mesmo modo de falha: o engenheiro que está saindo sabe exatamente o que aconteceu durante seu turno, e nada desse conhecimento sobrevive à transferência. O engenheiro entrante recebe uma mensagem no Slack dizendo que algo aconteceu com os pagamentos, herda um painel repleto de picos inexplicados, e passa os primeiros vinte minutos de seu turno reconstruindo um contexto que já existia na cabeça de outra pessoa doze horas antes.
Por que o prompt força uma divisão por severidade
A estrutura separa deliberadamente «Problemas Ainda Abertos» de «Resolvido Durante o Turno» e «Lista de Observação», em vez de produzir uma lista plana do que aconteceu. Essa separação existe porque a falha de transferência mais perigosa não é um fato ausente — é um risco ativo enterrado no meio de uma parede de texto ao lado de cinco itens rotineiros já resolvidos.
Por que «resolvido» e «totalmente encerrado» são tratados como estados diferentes
A restrição que exige distinguir entre um incidente resolvido e um totalmente encerrado visa um erro específico e comum: aplicar uma mitigação, observar o sintoma desaparecer, e então escrever como concluído.
Por que a lista de observação tem sua própria seção
Nem tudo que vale a pena mencionar disparou um alerta. Um pool de conexões que está oscilando mais que o normal, uma métrica de latência em tendência de alta mas ainda abaixo do limite: esses são exatamente os sinais que se perdem em uma transferência verbal.
Use isso ao final de qualquer turno de plantão, rotação de incidentes, ou transferência de suporte em que o custo de perder contexto seja medido em minutos de reinvestigação.