Culture & Team
Holiday preparation handbook for senior engineers
10 August 2026
Before you leave for the Assumption break or any extended holiday, production must be able to run without you. The core requirement is simple: one page that any cover engineer can open at 02:00 and act on immediately. That page contains your emergency contact, the name of the primary backup, the escalation threshold (such as a high-priority incident or SLA breach), and direct links to six domain runbooks. Grafana OnCall handles on-call orchestration; the RACI table eliminates ambiguity about who owns what. This developer handbook for holidays preparation follows the transition taxonomy established in ISO/IEC 14764, which frames handover as a lifecycle process with documentation, training, and configuration management as central pillars, not afterthoughts.
60-second emergency quick start (pin this to your team channel):
- Emergency contact: [Your name] — reachable only for P0/P1 via [single channel, e.g. Signal]
- Primary backup: [Name] — first call for all production issues
- Escalation threshold: SLA breach or >20% error rate sustained for 10 minutes
- Runbook index:
docs/runbooks/index.mdin the main repo - On-call tool: Grafana OnCall — schedule pinned at [URL]
- Rollback command:
kubectl rollout undo deployment/<name> -n <namespace> - Certificate check:
openssl s_client -connect <domain>:443 | openssl x509 -noout -dates
Pro Tip: Pin the emergency quick start as a pinned message in your team’s Slack or Teams channel and commit it to the repo root as HANDOVER.md. A cover engineer should never need to search for it.
Key takeaways
A complete holiday handover requires a 60-second emergency quick start, six domain runbooks with RACI ownership, tuned alert routing, and at least one dry-run drill completed before departure.
| Point | Details |
|---|---|
| 60-second quick start | Commit HANDOVER.md to the repo root and pin it to the team channel before departure. |
| RACI with primary and backup | Assign a named primary and backup per domain; validate access and one shadowed shift before leave. |
| Alert label tuning | Apply holiday-defer and holiday-page labels in Prometheus Alertmanager; revert on Day 1 of return. |
| 90-day capture schedule | Record walkthroughs as work occurs across three phases; hand over incrementally, not the week before leave. |
| Vicedomini Softworks | Provides 3–7 day handover engagements covering runbook authoring, RACI facilitation, and dry-run sessions. |
Table of Contents
- What does a complete handover package contain?
- Which domain runbooks does every handover require?
- How do you assign ownership to eliminate single points of failure?
- How should you tune alerts and on-call routing for holiday periods?
- What is the deployment freeze policy for the holiday window?
- How does the 90-day capture schedule prevent last-minute handover panic?
- What does the access and secrets verification checklist cover?
- How do you validate the handover package with a dry run?
- What does the post-holiday reset process look like?
- Copy-and-use templates for your repo
- How do you manage third-party vendor support during the holiday window?
- How do global teams coordinate time zones during handover and on-call shifts?
- What contingency plans cover extended absences or unplanned gaps?
- Why the 60-second quick start matters more than the architecture diagram
- When an external engineering partner can accelerate your handover readiness
- Sources
- FAQ
What does a complete handover package contain?
Lead engineers consistently report that the most common failure is a handover written the week before leave with no clear ownership structure. A complete package has six parts.
The cover memo states your absence dates, the cover person’s name and contact, the backup’s name, and one rule: what constitutes an emergency worth interrupting your holiday. Keep it to half a page.
The inventory table lists every critical routine, its owner, backup, frequency, and runbook link:
| Routine | Owner | Backup | Frequency | Runbook |
|---|---|---|---|---|
| Database backup verification | Alice | Bob | Daily | docs/runbooks/db-backup.md |
| Certificate expiry check | Bob | Carol | Weekly | docs/runbooks/certs.md |
| Deployment pipeline health | Carol | Alice | Per release | docs/runbooks/cicd.md |
| Cost anomaly review | Alice | Bob | Weekly | docs/runbooks/finops.md |
The escalation path names who to call after the backup, with timeouts. The handover archive is the entire package committed to the repo and tagged holiday-handover-YYYY-MM-DD.
Pro Tip: Send the cover person the package three days before you leave, not the morning of departure. Ask them to read it and raise one question — that question will reveal the gap you missed.
Which domain runbooks does every handover require?
A practising platform engineer’s template demonstrates that a single entry page with drill-down domain runbooks can orient any responder in under 60 seconds. Six domains require their own runbook.
| Domain | Minimum contents | Emergency action |
|---|---|---|
| Platform & Infrastructure | Red flags, kubectl commands, node drain procedure |
Scale down non-critical pods; alert on-call |
| CI/CD | Pipeline failure codes, retry steps, rollback trigger | Disable auto-deploy; notify team |
| Observability | Grafana dashboard URLs, Prometheus Alertmanager silence commands | Silence noisy alert; open ticket |
| Security | Incident classification, MFA reset path, vault access | Isolate affected service; escalate to security lead |
| FinOps | Cost spike threshold, AWS/GCP budget alert links | Tag anomaly; defer investigation to return |
| IaC | Terraform state lock release, drift detection commands | Lock state; do not apply; escalate |
Each runbook follows a three-layer structure: what the service does, red flags to watch for, and step-by-step fixes with exact commands. Architecture diagrams are useful context but secondary to the fix commands.
- Every runbook links back to the index page
- Every runbook includes a “last verified” date and the name of the person who verified it
- The index page (
docs/runbooks/index.md) is the single entry point; it lists all six domains with one-line descriptions and direct links
How do you assign ownership to eliminate single points of failure?
RACI-style ownership with a primary and a backup per domain is the most reliable structural defence against single points of failure during reduced staffing.
Escalation timeouts must be explicit: acknowledgement within 15 minutes, first call to backup at 30 minutes, secondary escalation at 60 minutes, management notification at 90 minutes. Before departure, validate that every backup has working access and has completed at least one shadowed shift with the primary present.
How should you tune alerts and on-call routing for holiday periods?
Temporary severity tuning and explicit Alertmanager labels are the fastest levers to reduce night-time paging while preserving traceability through ticketing. The process follows four steps:
- Audit every active alert and classify it: junior-actionable, senior-required, or emergency.
- Apply a
season: holiday-deferlabel to junior-actionable alerts and route them to the ticket queue rather than paging on-call. - Apply
season: holiday-pageto senior-required and emergency alerts; route these to the active Grafana OnCall schedule. - Configure PagerDuty or Grafana OnCall escalation policies to match available skill levels during the holiday window.
| Severity | Label | Routing | Timeout |
|---|---|---|---|
| P1 Emergency | holiday-page |
Grafana OnCall → PagerDuty | 5 min |
| P2 Senior-required | holiday-page |
Grafana OnCall | 15 min |
| P3 Junior-actionable | holiday-defer |
Ticket queue (Zammad/OTRS) | Next business day |
| P4 Informational | holiday-defer |
Ticket queue | On return |
Prometheus Alertmanager handles the label-based routing via its route and receiver configuration blocks. A sample rule routes any alert carrying season="holiday-defer" to a webhook receiver that creates a Zammad ticket, bypassing paging entirely.
Pro Tip: Set a calendar reminder for your first day back to revert all holiday alert labels to avoid suppressing necessary alerts.
What is the deployment freeze policy for the holiday window?
The triage matrix governs which tasks run, wait, or are deferred during the holiday window.
| Category | Examples | Action |
|---|---|---|
| Must run | Backups, replication, certificate renewals, security patches | Automated; verify before departure |
| Can wait | Minor dependency updates, non-critical config changes | Queue for return |
| Actively deferred | Major version upgrades, database migrations, infrastructure reboots | Freeze; document deferral reason |
A deployment freeze applies from 48 hours before the holiday window opens until 48 hours after the primary engineer returns.
Certificate expiry is a common silent failure during holidays. Renew certificates well before departure and verify that ACME automation has successfully renewed certificates recently without errors. Run openssl s_client -connect <domain>:443 against every public endpoint and confirm the expiry date is beyond the return date plus a two-week buffer.
Pro Tip: Add a certificate expiry check to your CI/CD pipeline as a scheduled job. A failed check should create a P2 alert, not a P4 informational one.
How does the 90-day capture schedule prevent last-minute handover panic?
Engineers who recorded routine work over 90 days found walkthrough libraries far more useful than a document written the week before leave. The schedule below distributes the work across three phases:
- Day 90 to Day 60: Identify every recurring workflow. Record a screen walkthrough for each one as it occurs naturally. Store recordings in a shared drive with a consistent naming convention:
YYYY-MM-DD_domain_task.mp4. - Day 60 to Day 30: Capture trigger-based work as it happens. For each incident or deployment, record a short narrated walkthrough of the decision process, not just the commands.
- Day 30 to Day 0: Record judgement-call heuristics as short scripts. Run one live walkthrough session with the cover person. Identify gaps and fill them.
Walkthrough template for each recording:
- What this covers: one sentence
- When to use it: trigger condition
- Steps: numbered, with exact commands
- Who to call if this fails: name and contact
Store all recordings and scripts in the repo under docs/walkthroughs/. Link each walkthrough from the relevant domain runbook.
What does the access and secrets verification checklist cover?
Before departure, every credential the cover person needs must be verified as working. Maintaining overlapping access for a short period allows the primary and cover person to validate credentials during a real or simulated incident before the primary leaves.
For remote access security, verify MFA is active on every shared service account, confirm vault paths are accessible to the cover person, and document which accounts require break-glass procedures. Rotate all shared credentials immediately after the cover period ends and the primary has confirmed handover is complete.
How do you validate the handover package with a dry run?
Synthetic alert drills reveal broken notification routes before a real incident does. Quarterly dry tests of the complete alerting and escalation chain are the recommended cadence; run one specifically before any extended holiday.
- Fire a synthetic alert in Prometheus Alertmanager using a test label:
alertname="HolidayDrillTest". - Confirm the alert routes correctly through Grafana OnCall or PagerDuty to the cover person.
- The cover person acknowledges within the defined timeout and opens a ticket in Zammad or OTRS/Znuny.
- The cover person resolves the synthetic incident or escalates correctly per the RACI table.
- Log the result: alert fired at [time], acknowledged at [time], resolved/escalated at [time], gaps identified: [list].
Acceptance criteria: the cover person can resolve or correctly escalate every synthetic scenario without contacting the primary. Tickets preserve full traceability. Any gap discovered during the drill requires a runbook update before departure.
- Log dry-run results in
docs/drills/YYYY-MM-DD-drill-log.md - Attach the log to the handover archive tagged
holiday-handover-YYYY-MM-DD
What does the post-holiday reset process look like?
| Reset task | Owner | Timing |
|---|---|---|
Revert all holiday-defer and holiday-page labels |
Primary engineer | Day 1 of return |
| Resume normal alert severities in Prometheus Alertmanager | Primary engineer | Day 1 of return |
| Rotate shared credentials and revoke cover-period access | Primary + backup | Within a few days of return |
Archive handover sheet to docs/archive/ |
Primary engineer | Day 1 of return |
| Schedule backlog review meeting | Engineering lead | Within 48 hours of return |
| Run debrief: what happened, what was deferred, runbook updates | Full team | Within a few days of return |
The debrief template has four fields: what incidents occurred, what work was deferred and why, who requires follow-up, and which runbooks need updating based on what actually happened. Every deviation from the expected escalation path is a documentation gap; the debrief converts those gaps into runbook updates before the next holiday cycle.
Pro Tip: Treat the debrief as a lightweight post-mortem. If the cover person had to improvise at any point, that improvisation belongs in the runbook.
Copy-and-use templates for your repo
| Template | Use case | Where to store |
|---|---|---|
| Emergency quick start (one page) | Pin to team channel; commit as HANDOVER.md |
Repo root |
| Domain runbook skeleton | Copy per domain; fill in red flags and commands | docs/runbooks/<domain>.md |
| RACI matrix | Assign primary and backup per domain | docs/runbooks/raci.md |
| Drill log | Record synthetic alert results | docs/drills/YYYY-MM-DD-drill-log.md |
| 90-day capture calendar | Track walkthrough recording milestones | docs/walkthroughs/capture-calendar.md |
| Secrets index | List vault paths, expiry dates, access review dates | docs/security/secrets-index.md |
Keep every template as a living document: link it from the repo README, add a last-reviewed frontmatter field, and schedule a quarterly review. A template that is not reviewed becomes stale faster than the systems it documents.
- Mark templates
holiday-readyin your wiki only after a dry run confirms they work end-to-end - Version-control all templates; use git tags to mark the state at each handover
How do you manage third-party vendor support during the holiday window?
Third-party dependencies introduce risk that internal runbooks cannot fully mitigate. Before departure, audit every vendor your production systems depend on: SaaS providers, cloud platforms, CDN operators, and payment processors. For each, document the support tier active during the holiday period, the escalation contact, and the expected response time.
Vendors operating on reduced holiday schedules may not meet their standard SLA commitments. Where a vendor’s holiday support tier is slower than your incident response requirement, either pre-open a support ticket for any known risk, or document a manual workaround in the relevant domain runbook. For backup and recovery dependencies, verify that automated backup jobs do not depend on a vendor API that may be rate-limited or unavailable during peak holiday periods.
Establish a communication firewall: one documented emergency contact per vendor, stored in the secrets index, with the cover person confirmed as authorised to raise tickets on the organisation’s behalf.
How do global teams coordinate time zones during handover and on-call shifts?
For teams spanning EMEA and North America, the holiday window rarely aligns cleanly. The Assumption break (15 August) affects EMEA teams heavily but may leave North American colleagues at full capacity, creating an asymmetric coverage opportunity that is frequently under-exploited.
Map every on-call shift to a named individual and their local time zone before the holiday window opens. Grafana OnCall and PagerDuty both support time-zone-aware schedules; use them to prevent a shift from defaulting to an engineer whose local time is 03:00. For handover sessions, schedule the live walkthrough during a two-hour overlap window where both the primary and cover person are within normal working hours. Document the agreed overlap window in the cover memo so there is no ambiguity about when the primary is reachable for questions.
Where no overlap exists, record the handover walkthrough and require the cover person to watch it and submit written questions before the primary’s last working day.
What contingency plans cover extended absences or unplanned gaps?
Unplanned coverage gaps, whether from illness, a family emergency, or an extended absence, require a pre-authorised escalation path that does not depend on the primary engineer’s availability. The RACI table’s backup column is the first line of defence; the secondary escalation column covers the scenario where the backup is also unavailable.
For absences extending beyond two weeks, or where the backup lacks the depth to handle a specific domain independently, document a pre-approved engagement with an external engineering partner. That engagement should be scoped in advance: the partner needs access to the runbook index, the secrets index (read-only), and the Grafana OnCall schedule. Pre-authorise the cover person to activate that engagement without requiring management approval, provided the incident meets the defined P1 threshold.
Contingency planning also covers the scenario where the cover person themselves becomes unavailable. The secondary backup named in the RACI table must have working access and must have attended at least one dry-run session, even if they were not the primary cover person.
Why the 60-second quick start matters more than the architecture diagram
The conventional wisdom in engineering handovers is that more documentation is always better. The evidence points in the opposite direction. A cover engineer at 02:00 does not need a 40-page architecture document; they need one page that tells them what is broken, what the red flag looks like, and exactly which command to run. The three-layer runbook structure — what it does, red flags, step-by-step fixes — is more effective for holiday coverage than exhaustive diagrams precisely because it reduces cognitive load at the moment of highest stress.
The 90-day capture schedule is the other insight that most teams ignore until it is too late. Handover documentation written the week before leave is almost always incomplete, because the engineer writing it cannot remember every judgement call they made over the past year. Capturing walkthroughs as work occurs transforms handover from a last-minute sprint into a maintenance asset that also serves as onboarding material for new team members.
The RACI table’s value is not the table itself; it is the conversation it forces. When a primary and backup sit down to fill in the RACI, they discover access gaps, undocumented procedures, and single points of failure that would otherwise surface only during an incident. That conversation, held 90 days before departure rather than 48 hours before, is where the real risk reduction happens.
When an external engineering partner can accelerate your handover readiness
For engineering leads who need to build a complete handover package quickly, Vicedomini Softworks offers focused engagements scoped to 3–7 days: runbook authoring across all six domains, RACI facilitation, Grafana OnCall and PagerDuty integration, and two facilitated dry-run sessions. The direct engineering model means the team working on your handover is the same team that understands your production architecture, with no account-manager layer adding latency to decisions.
For organisations where the cover person lacks depth in a specific domain, Vicedomini Softworks can provide temporary on-call support during the holiday window, with access scoped to the minimum required and credentials rotated on return. The engagement is structured around your existing runbooks and escalation chain, not a replacement for them. Review the full services overview or explore client engagements to understand the scope of prior maintenance and support work.
Sources
Alerting and monitoring: Vacation mode: monitoring and alerting with reduced staffing covers severity reclassification, Alertmanager label routing, and ticket queue integration. Holiday monitoring coverage for reduced senior presence covers junior-actionable design and automated retries.
Handover taxonomy: Software system handover and transition taxonomy provides the academic framework for transition phases, roles, and documentation standards.
Runbook structure: How I built a DevOps handover document that could run without me is the practitioner template for the single-entry-page approach.
Knowledge capture: How to hand off a workflow before you go on leave details the 90-day incremental capture approach.
Ownership and RACI: The CTO PTO Crisis covers RACI-style ownership and the single-point-of-failure risk.
Communication boundaries: Vacation handoff protocol, scripts and checklists covers the communication firewall and out-of-office decision boundaries.
Tools: Grafana OnCall (on-call orchestration), PagerDuty (escalation policies), Prometheus Alertmanager (label-based routing), Zammad and OTRS/Znuny (ticket queues), Let’s Encrypt via Traefik or Caddy (ACME certificate renewal), HashiCorp Vault (secrets management). Store all templates under docs/ in your main repo and mark them holiday-ready only after a successful dry run.
- Vacation mode: monitoring and alerting with reduced staffing | DATAZONE
- How I built a DevOps handover document that could run without me
- How to hand off a workflow before you go on leave — UIHike Blog
- Three‑layer handoff framework and holiday monitoring coverage | ServerScout
FAQ
What is the minimum a cover engineer needs to handle a 02:00 incident?
One page: the emergency quick start with the escalation threshold, a rollback command, and links to the six domain runbooks. Everything else is supporting detail.
How long before departure should the handover package be ready?
The full package should be ready and reviewed by the cover person at least three days before departure, with the dry-run drill completed at least one week before.
How do you tune Prometheus Alertmanager for a holiday period?
Add a season: holiday-defer label to junior-actionable alerts and route them to a ticket queue receiver; apply season: holiday-page to P1 and P2 alerts and route them to Grafana OnCall or PagerDuty. Revert both labels on the first day back.
When should a cover engineer escalate to an external partner?
When the backup is unavailable and the incident meets the pre-defined P1 threshold, the cover person should activate the pre-authorised external engagement without waiting for management approval, provided the escalation path documents that authority.
How often should dry-run drills run outside of holiday periods?
Quarterly, per practitioner guidance, with one drill specifically timed to run within two weeks of any planned extended absence.