The on-call handoff checklist that stops Monday surprises

On-call duty ends at a specific time. The person who took the shift is eager to close the laptop. The person who is starting the next shift is still catching up on the weekend. In that window of uncertainty, something can slip through the cracks. A critical alert goes unhandled. A patch intended for a deployment never gets applied. A system that should have been patched is left vulnerable.

The outcome is often a Monday morning scramble where the on-call person has to do three or four hours of catch-up before they can handle incoming issues. This not only burns out the person on-call but also creates blind spots that can grow into outages.

A simple handoff checklist can prevent these surprises. It forces you to document everything that happened during the shift and everything that needs to happen next. It works equally well for solo operators and for small teams.

Start with a handoff meeting

The handoff should happen at the scheduled end time, regardless of whether an incident is in progress. If an incident is ongoing, pause it for 10 to 15 minutes, document the current state, and then resume. The documentation is more important than continuity in the moment.

The person leaving the shift leads the meeting. The person starting the shift listens and takes notes. Both should be present during this window. Do not rely on email or chat messages as a substitute for a conversation.

The meeting should last no longer than 30 minutes. If it is longer, something is wrong with your processes. Keep it brief and focused on what matters: alerts that are still open, tickets that need follow-up, and decisions that have been deferred.

Document all open alerts

Before leaving, review every alert that is currently open. For each alert, note the system, the current status, and any actions already taken. If an alert is still unresolved, explain why it is not urgent enough to keep the person on-call from stepping away.

Common reasons for leaving an alert open include: it is informational, it is being monitored by another team, or it requires a manual investigation that can be done during the next shift.

Do not just say "ticket 123 is open". Specify what that ticket is about and what its current state is. This prevents the incoming person from having to dig through the ticket system to understand what is happening.

List all tickets and work in progress

Beyond alerts, there may be tasks that are in progress but not yet complete. These can include code deployments, configuration changes, or security patches. Document each one with its status, what has been done, and what remains.

For example, you might have deployed a change to production that is being monitored. Or you might be in the middle of a performance investigation. Both of these should be explicitly listed so the next person knows where to pick up.

If a task cannot be completed during the shift, specify a completion time or a decision on what to do next. For example, "the performance investigation requires additional logs that will be available after the weekend" or "this patch will be reviewed on Tuesday morning".

Capture any decisions and assumptions

During a shift, you often make quick decisions that rely on assumptions. For example, "we assume this is a transient issue and will monitor for another hour" or "we defer this change until it can be tested in staging".

Document those decisions and the assumptions behind them. If the assumptions turn out to be wrong, the next person will know exactly what to do. If they were correct, the documentation serves as a record for future reference.

Also note any changes to your standard processes. For example, if you temporarily bypassed a step to unblock an issue, explain why and specify whether you will revert it or make it a permanent change.

Clarify the on-call expectations for the next shift

Make sure the person starting the shift understands what to expect. This includes your operating hours, escalation procedures, and what constitutes an emergency. If your on-call policy changes, document the new policy before the shift ends.

Explain how alerts will be communicated. Are you using email, chat, or a monitoring tool? What is the expected response time for different types of alerts? If there are critical systems that require 24/7 attention, make that clear upfront.

Finally, ask if there is anything the incoming person needs access to. This might include credentials, documentation, or permissions. Ensure that these are shared securely and recorded in your access management system.

Follow up at the start of the next shift

The handoff does not end when the person on-call closes their laptop. The next person should review the handoff documentation before they begin their shift. If anything is unclear, they should reach out immediately.

A quick 5-minute review can prevent hours of confusion. It also provides an opportunity to confirm that the handoff was complete and accurate. If something was missed, document it and add it to your checklists.

Your on-call handoff process should be simple enough that anyone can follow it without preparation. When the shift changes, the checklist ensures that no critical information is left behind.

Want the full version?

Ops Starter Kit Vol. 2 — A$27 | Agent Ops 24/7 — A$19 | The Automation Starter Pack — A$19 | Hive80 Ops Mega Bundle — A$29 | free: The First 30 Minutes