The Monitoring Handoff Problem
Most monitoring setups work because one specific person remembers how. That person leaves, and the monitoring quietly stops being monitoring.
Every small business has somebody who "just handles the ops stuff." They set up the monitoring. They own the alerts. They know why that one check has a weird exception, and which vendor's status page is unreliable, and what the runbook is for the quarterly certificate thing.
Then they leave. Or change roles. Or go on parental leave. And six months later, the monitoring is still running, but it isn't really monitoring anymore. Because the mental model that made it work went with them.
This is the handoff problem, and it's nearly universal in small-business ops. It's also fixable, once you see it.
Why monitoring is especially vulnerable
Some operational things survive staff turnover well. A documented deploy process. A customer support playbook. A sales CRM. These have artifacts — written procedures, tickets, records of past decisions — that make the knowledge portable.
Monitoring tends to be different. The artifact is the system itself: dashboards, alert rules, thresholds, on-call routing. The context — why the threshold is 80% and not 90%, why this alert is paged but that one isn't, why the weekly cron is a warning not a page — lives in somebody's head.
When they leave, the system looks fine. The alerts still fire. Someone else takes over on-call. But the new person is working from the surface features, not the reasoning. They don't know which alerts are known-flaky, which thresholds are deliberate, which checks were added after a specific incident. They treat the whole system as given, rather than as a set of decisions that can be revisited.
Over time, decisions accumulate that contradict the original reasoning. The system drifts. Eventually something breaks that the original setup would have caught, but the current version doesn't.
What gets lost at handoff
Specifically, the things that tend to evaporate:
Threshold reasoning. "Why is the disk-space alert at 75% on this box but 90% elsewhere?" Because the original person knew this box grows slower than the others. New person doesn't, and retunes it to match. Next time the disk fills, there's less warning.
Known flakes. "That alert fires every Tuesday at 4 AM, ignore it." New person doesn't know. They either get paged and get angry, or they suppress the alert entirely and lose the real signal with it.
Relationships with vendors. The registrar you always call to resolve renewal weirdness. The support engineer at your email provider who actually responds. The status-page convention for your CDN. All of it portable in principle; rarely written down.
Incident history. "We had this problem in 2023, the fix was X." New person re-learns it, possibly re-implementing a workaround that didn't last.
Severity intuition. When a weird alert fires, the original person knows whether it's a real problem or a known oddity. New person doesn't have the base rate.
Channel hygiene. Which channels are for pages, which are for info, who watches each one. Drift in this area is how alerts end up going to inboxes nobody reads.
The handoff that actually works
A monitoring handoff is done properly if the new person can, within a month:
- Name every alert that can page them
- Explain what each alert means operationally, not just what the threshold is
- Locate the runbook (or at least the ownership) for each alert
- Identify the "known weird" alerts and why they exist
- Recognise which past incidents have shaped the current setup
If any of those are missing, the handoff didn't really happen. The new person is running the system, but they're running a copy of it they don't fully understand.
How to make monitoring portable
The fix isn't heroic documentation. Nobody has time for the "write down everything you know" exercise, and the resulting document is usually stale within six months anyway.
What works better is structural knowledge transfer — building monitoring so the context lives alongside the system:
Every alert has a runbook field
Two lines per alert, attached to the alert definition itself. What does this mean, what's the first check, who owns it. Lives where the alert lives, not in a separate wiki that people stop updating.
Ownership is in the alert, not in a human's head
Tag every alert with the owner — a role, a team, a specific person. When ownership changes, update the tag. Never leave the answer as "whoever the ops person is."
History stays in the system
Use commit messages, change logs, or an ops journal that documents why thresholds changed and what incidents drove monitoring additions. The next person needs the reasoning, not just the artifact.
Quarterly pair review
Twice a year, two people review the alert list together. Not to rewrite documentation — to test whether both humans can explain each alert. Gaps become action items.
The 'leaving on holiday' test
Before someone with ops knowledge takes extended leave, run a tabletop: walk through likely alerts and have the person covering explain what they'd do. Gaps get closed before they become urgent.
None of this is hours of ceremony. Runbooks can be one-liners. Ownership tags are free. The pair review takes ninety minutes per quarter. The handoff cost is paid down incrementally rather than accumulated and dumped on whoever's next.
The single-founder version of this problem
If the person is a founder, the problem is more acute. There's often no "next person" in the queue. The single-founder ops stack is its own piece, but the handoff principle applies in a different form: even with no successor planned, the system has to survive a two-week disappearance. A broken leg, a family emergency, a week completely offline. If the monitoring only works because you're there, the business doesn't really have monitoring — it has you, doing monitoring, in real time.
The cost of skipping this
Skipped handoffs compound. The first departure leaves small gaps. The second departure, if the context accumulated more since, leaves bigger ones. Eventually you end up with monitoring that's technically running but practically ungoverned — a forest of alerts that nobody can fully explain, each one defensible in isolation but collectively unreadable.
This connects back to alert fatigue, which is often a downstream symptom of repeated bad handoffs. When nobody can explain why an alert exists, nobody has standing to delete it, so the alert list grows forever.
The pillar on boring IT for SMBs frames this as a team durability issue rather than a documentation issue. The right frame — monitoring that survives people — leads to different choices than the wrong frame, which treats it as "we should write better docs." Write fewer, better-structured artifacts, attached to the system itself, updated incrementally, reviewed on a schedule. That's a system. "We should document everything" is not.
The quick test
If you've been running monitoring for more than a year and haven't done a conscious handoff exercise, try this: ask the most recent new person on your team to walk you through the alert channel. Every alert. What does it mean, when should they act, who owns it?
The size of the gap between what they can explain and what's actually running is the size of your handoff debt. That's the work. Consolidating the monitoring itself onto a smaller number of tools — for instance, folding domain, SSL, uptime, DNS, and vendor signals into a single dashboard via Site Watcher — makes the handoff meaningfully cheaper, because there's less surface area for the new person to learn.