Vacation Handoff Template: What to Include

The typical engineer vacation handoff is a list of things they own. "I own the payments service, the data pipeline, and the on-call rotation for Platform." That's not a handoff. That's a job description. Nobody reading it knows what's actually happening, what decisions are open, what to do when something breaks, or what you'd say if you were there to answer.

Good vacation handoffs are rare because they require thinking through a different question: not "what do I own?" but "what does someone need to know to act on my behalf while I'm gone?" That's a harder question, and most engineers don't have a framework for answering it efficiently.

Here's the framework — and the five things almost every vacation handoff template leaves out.

The standard fields (that you probably already include)

Most handoff templates include:

• What systems or projects you're responsible for
• Who to contact for specific questions
• Your out-of-office dates and when you'll return
• An emergency contact method

These are table stakes. They're necessary but nowhere near sufficient. An engineer receiving only these four things will spend your vacation either stalling or guessing.

The five things almost every handoff forgets

1. Current decision state

What decisions are open right now — not just what projects exist, but where specific decisions stand? An open decision is a gap in authority. If you don't hand it off explicitly, either it doesn't get made (work stalls) or it gets made without the context you have (decision quality degrades).

For every significant open decision, include: what the decision is, what options are on the table, what your lean was and why, and who has authority to make it in your absence. Two sentences per decision is fine. The goal isn't documentation — it's handoff.

2. Unresolved questions

Different from open decisions: unresolved questions are things you've been actively working to answer that haven't landed yet. A vendor hasn't responded. A technical investigation is in progress. Someone asked something you were researching.

These need to be handed off because the person covering you may receive the answer — and without context, they won't know what to do with it. For each unresolved question: what the question is, what you know so far, who you're waiting on, and what action should happen if and when the answer arrives.

3. What "good" looks like for in-flight work

You probably have work in progress that should continue while you're out. What does a successful outcome look like? What's the definition of done that would let the covering engineer close the loop? Without this, engineers covering you default to conservative behavior — they do minimum viable maintenance but don't advance work because they're not sure what "done" means in your absence.

One sentence per in-flight item: "This is done when the CI pipeline is green and Sarah has approved the PR." "This is done when the customer confirms the bug is resolved in staging." That's enough.

4. Who should and shouldn't interrupt you

Most handoff templates include an emergency contact. Very few specify what constitutes an emergency. The result: whoever is covering you applies their own judgment about what's urgent, which is usually more conservative than yours. You get Slack messages for things you wouldn't have considered emergencies.

Be specific. "Interrupt me only if production is down AND both of the following are true: (1) the revenue impact is over $10K/hour and (2) Sarah has already been looped in and needs me." The specificity feels excessive until the first time it prevents a 2 AM call about a non-critical alert that the covering engineer wasn't sure about.

Also specify: who should not have the emergency contact information. "Please don't share my phone number with the customer success team — any customer escalations can wait for my return or go to the on-call manager."

5. What would cause you to want to be reached

The inverse of escalation thresholds: are there situations where you'd actually want to know, even if they don't meet the emergency threshold? This is the nuance that most templates miss.

For example: "If the Q3 infrastructure budget discussion comes up at the leadership meeting on Thursday, I'd want to know what was decided — not interrupted, just informed via Slack when I'm back or whenever you have a moment. It won't change my vacation, but it affects my priorities when I return."

These aren't interruptions. They're context transfers. They help you return to work informed rather than walking into a changed landscape with no map.

The complete template

Here's the full structure, in one place:

• Out-of-office dates and return date
• Coverage contact: [Name, how to reach them, what they're authorized to handle]
• In-flight work: [Status, blockers, definition of done for each item]
• Open decisions: [Decision, options, your lean, who can decide in your absence]
• Unresolved questions: [Question, what you know, who you're waiting on, what to do with the answer]
• Emergency threshold: [The specific conditions that warrant interrupting you + how to reach you]
• Keep me informed (not interrupted): [Topics where you'd want a Slack message when you're back or convenient]
• What not to decide without me: [Decisions you want to make yourself — hold until return]

Frequently asked questions

How far in advance should I write this?

Write it two to three days before you leave. Writing it the morning of departure means you're rushed, you'll miss things, and your covering engineer has no time to ask clarifying questions. Two to three days gives you a window to review in-flight work, identify open decisions you've been carrying in your head but not documenting, and do the handoff sync before you're mentally already gone.

Should I do a synchronous handoff meeting or is a document sufficient?

For absences under a week: a well-written document with a 15-minute "any questions?" sync is sufficient for most situations. For absences over two weeks: a synchronous walkthrough of the document is worth it, particularly for complex systems or high-stakes in-flight work. The document is the foundation; the conversation is for clarifying questions and confirming the covering engineer actually has what they need.

What if I don't have a specific person covering me?

Write the handoff document anyway and share it with your team or manager. A clear documented state is useful even when coverage is distributed across multiple people. It prevents the "I didn't know that was in-flight" conversation that happens when work stalls and nobody owns the gap. Even distributed coverage needs declared state.