What should an operational handover include?

The minimum useful record

An operational handover is a transfer of decision context. A title alone, or a Jira issue URL with no explanation, leaves the incoming person to reconstruct the situation. Use the same core fields on every handover, then add detail only where risk warrants it.

The fields below describe the handover, not necessarily a new set of Jira issue fields. If your team uses Jira alone, a defined issue template can carry them. If you use Handoff Pulse, the structured handover sits alongside the linked Jira work.

• Title and service: identify the operational object, not just the symptom.
• State and timestamp: what is happening now and when was it observed?
• Impact and priority: whom does it affect and how urgent is action?
• Owner and next action: who acts, when and against which success condition?
• Risk or blocker: what could worsen, and what prevents progress?
• Jira reference: link the underlying issue where one exists.

Distinguish priority from impact

Impact describes the observed breadth or severity of the effect: for example, one internal job is delayed versus a customer-facing service is unavailable. Priority is the team’s decision about response order. Urgency may depend on a time window, an upcoming change or a contractual escalation path; it is not identical to impact.

Write both when they differ. A low-volume failure that must be addressed before a scheduled batch can be time-critical. Conversely, a serious event already mitigated may still require investigation, but the immediate next action changes. Do not copy a Jira priority label without checking whether it still reflects the current operational decision.

Separate observation, hypothesis and decision

Use plain labels in the narrative: ‘Observed’, ‘Suspected’, ‘Done’ and ‘Next’. Record the evidence that supports each observation: a log reference, metric window, Jira issue or runbook section, where access is appropriate. Avoid copying customer data or credentials into a handover simply to make the record self-contained.

The distinction matters during an incident. If a suspected root cause is presented as fact, a receiving engineer may skip a viable diagnostic branch. If a mitigation is recorded without its expiry or trade-off, it may persist for several shifts without anyone owning the rollback.

Specify the next action as a test

An action should have an actor, a time or trigger, a check and an outcome. For example: ‘At 22:00 UTC, the receiving operator compares the 15-minute error rate with the agreed alert threshold; if exceeded, page the service owner according to the incident runbook.’ This is more useful than ‘keep watching’. Use an agreed threshold rather than inventing one in the handover.

If nobody can name an owner, make assignment the next action and escalate the ownership gap. Avoid several equally urgent actions without an order: list the first decision, the fallback and any deadline. The linked Jira issue can contain the detailed implementation plan.

Worked example and anti-example

Weak: ‘OPS-248, payment queue slow, please check.’ Stronger: ‘OPS-248; payment queue; 21:45 UTC backlog rising, retries stabilised throughput, cause unknown; on-call operations owns receipt; check backlog and error trend at 22:00 UTC; escalate under the existing runbook if the agreed trigger is met; retry adjustment must be reviewed on the next shift.’ The example values are illustrative, not a description of a live customer system.

The stronger record allows a receiver to answer four questions immediately: what is happening, what has been tried, what remains uncertain and what it must do next. It also marks a temporary change that could otherwise become an undocumented permanent setting.

Keep the record current

Update the state when evidence changes, not only at shift boundaries. Acknowledge receipt separately from resolving work. Carry an item forward only if there is still a next action or open risk, and state what changed since the previous handover. Close stale records after confirming that the operational decision is complete.

As a review check, ask whether each open handover has a reachable owner, a recent state, a linked issue where appropriate and a next action. Those four conditions are more valuable than a long free-text note with no accountability.