Assemble an on-call rotation handoff

Why use this

1. A new on-call engineer needs to know what still matters, not just what generated the most messages. Resolved incidents, mitigated-but-open issues and recent deployments can look equally active when paging history and escalation discussions are read separately.

2. This job could turn scattered operational context into a concise handoff with evidence-linked states. Explicit owners, next checks and unresolved questions would help the incoming rotation continue work without assuming that silence means an incident is closed.

Why an agent / simpler alternative

Useful judgment

Reconcile operational timelines and distinguish current risks from historical noise.

Simpler alternative

Use a structured handoff form when the outgoing rotation already keeps it current.

Unsuitable when

The task would change incident status, page responders or perform remediation without authorization.

Proposed inputs

1. Name

   Rotation evidence

   Owner

   On-call lead

   Minimum scope

   Scoped paging events, incident threads and deployment records

   Quality check

   Align timestamps and identify the handoff cutoff.

2. Name

   Previous handoff and ownership map

   Owner

   Outgoing lead

   Minimum scope

   Open items, responsible teams and watch conditions

   Quality check

   Verify which items remain unresolved and who can clarify them.

Access and setup — proposed or unknown

Proposed minimum

1. Read authorized operational sources and prepare a staged handoff without sending or changing incidents.

Compatibility unknowns

1. Unknown: PagerDuty/Slack access, deployment correlation and source-retention coverage.

External actions requiring approval

1. Posting the handoff, paging people or modifying incident and deployment records.

Expected deliverable and review checks

Proposed artifact

Handoff draft with current status, evidence links, owner, next check and watch conditions for each open item.

Critical checks

1. Mitigation and resolution are not treated as identical states.

2. Recent deployments are described as context unless evidence supports causation.

Missing output evidence

No new run or output inspection in this editorial layer; see linked source-specific limits.

Failure signals and proposed responses

1. Signal

   A mitigation message is mistaken for a final resolution.

   Why it matters

   The incoming engineer may stop watching a recurring issue.

   Proposed response

   Retain the open follow-up and ask the outgoing owner to confirm the final state.

2. Signal

   A deployment shares an incident timestamp but is unrelated.

   Why it matters

   The handoff could direct investigation toward an unsupported cause.

   Proposed response

   Label temporal overlap and preserve alternative explanations until checked.

Effort and cost — unknown

Setup work

1. Define the cutoff, status vocabulary and handoff audience.

Ongoing review

1. Resolve ambiguous states and update the staged draft before posting.

Unknowns

1. Unknown: connector limits, source completeness and outgoing-team review effort.

First check — proposed, unexecuted

Status

proposed_unexecuted

Synthetic fixture

Synthetic records include a mitigated incident, an unresolved follow-up and a nearby unrelated deployment.

Acceptance checks

1. The follow-up remains open with an owner.

2. The deployment is not labelled causal without evidence.

Stop conditions

1. Incident remediation, restricted-source access or unapproved communication is needed.

Limits

1. A handoff organizes known operational evidence; it cannot guarantee that every active risk has been captured.