Every MSP contract has a line about uptime. Almost none of them have a line about what happens in the gap between "something broke" and "someone with tier-3 knowledge is looking at it." That gap is where the real cost of an outage lives, and it's almost never scoped, priced, or planned for — it's just absorbed, quietly, by whoever's on call.
the cost that doesn't show up on the SLA
An SLA measures downtime in hours and minutes. It doesn't measure the cost of downtime, and those are very different numbers. A small business running on a single file server that goes down mid-day isn't just losing "two hours of uptime" — it's losing two hours of every employee who depends on that server, multiplied across payroll, multiplied by whatever revenue-generating work couldn't happen, plus the cost of whoever has to explain to a client why their deliverable is late.
// a rough number worth sitting with For a 15-person shop billing out at even a modest blended rate, two hours of total outage isn't "2 hours of downtime" — it's closer to 30 person-hours of blocked or degraded work once you count everyone who touches that system, plus whatever client-facing damage doesn't show up until later. The SLA credit for that outage, if there even is one, rarely covers a fraction of it.
That gap between what the SLA compensates and what the outage actually cost is the real number a business should care about — and it's driven almost entirely by how long it takes to get from "something's wrong" to "someone who can actually fix it is working the problem."
why the response gap is usually a tier-3 problem
Tier-1 and tier-2 support exist to triage and handle the common cases — password resets, printer queues, the known-issue playbook. They're fast because the problems are familiar. The expensive gap opens up the moment an issue falls outside that playbook: a DC that won't replicate, a permissions cascade that broke silently three deploys ago, a service account that expired and took down something nobody remembered depended on it.
That's tier-3 territory, and tier-3 territory is exactly where a shop's actual depth gets tested — because there's no script for "this specific weird thing," only judgment built from having seen enough weird things before.
what actually closes the gap: runbooks written from real incidents, not theory
The msp-tier3-toolkit repo exists because of that gap. It's not a theoretical "best practices" script collection — it's PowerShell pulled directly from real tier-3 helpdesk incidents, the kind of diagnostic and remediation steps that took real time to work out the first time and shouldn't take that long the second time.
That distinction matters more than it sounds like it should. A script written from a textbook handles the textbook case. A script written from an actual 2am incident handles the edge cases the textbook doesn't mention, because those edge cases are exactly what made the original incident take so long to resolve. Every script in that toolkit exists because something specific broke in a specific, annoying way, and someone had to figure it out under time pressure.
the math on why this pays for itself immediately
A runbook that turns a 90-minute diagnostic slog into a 10-minute scripted check doesn't just save 80 minutes once — it saves 80 minutes every time that failure mode recurs, across every client environment where it might show up. If a single script prevents one client's two-hour outage from becoming a four-hour outage, it has already paid for the time spent writing it, and every subsequent use after that is pure margin on the time saved.
// the honest caveat Runbooks don't prevent outages — they compress the response gap once one happens. Prevention is a different problem (monitoring, patching cadence, redundancy) and a real toolkit needs both. But the response gap is the part that's cheapest to fix and most often ignored, because it's invisible until the moment you need it.
why this is a security-ops habit, not an MSP-specific one
This is the same instinct behind twenty years in security operations applied to a different domain: document the incident while it's fresh, turn the resolution into something repeatable, and make sure the next person — or the next agent — doesn't have to relearn what already cost someone real time to figure out. Tier-3 runbooks and Sentinel Prime's write-back-to-memory loop are the same idea wearing different clothes: don't pay the same cost twice.