Checklist
The NOC Runbook Checklist: 12 Things to Document Before You Outsource Night Coverage
Exactly what an outsourced NOC needs from you before go-live, what 'good' looks like for each item, and a runbook template you can copy.
Quick answer
Before an outsourced NOC can work your nights it needs twelve things: a client and asset inventory, network diagrams, monitoring thresholds, an alert-to-runbook map, an escalation matrix, client contact preferences, change windows and freezes, an access method, vendor and carrier contacts, approval boundaries, ticket standards, and a handover format. Missing items don't block you, but they lengthen onboarding.
The quality of your night shift is capped by the quality of your documentation. That's true whether the night shift is your own hire or an outsourced NOC. Here's the checklist we'd want from any MSP, and what "good" looks like for each item.
What should be in the inventory and network documentation?
1. Client and asset inventory
Every client, site and monitored device, with criticality. Good: it's exported from your RMM or documentation platform, not a spreadsheet someone updates "sometimes."
2. Network diagrams
Per client: WAN links and carriers, firewall and HA pairs, core switching, VPN tunnels. Good: one page per site, with circuit IDs on it.
3. Monitoring thresholds
What alerts, at which threshold, after how long. Good: thresholds are tuned so overnight alerts are mostly actionable.
Which runbooks and escalation rules does a NOC need?
4. Alert-to-runbook map
For each common alert type, which runbook applies. Good: the top 20 overnight alert types each have a runbook.
5. Escalation matrix
Who gets contacted, in what order, after how long, by which channel. Good: it includes severity definitions and a fallback when nobody answers.
6. Client contact preferences
Which clients want a call, which want a text, which want nothing until 7 AM. Good: it's stored per client in your PSA.
What are the operational guardrails?
7. Change windows and freezes
Approved maintenance windows, end-of-quarter freezes, client blackout periods. Good: shared in the evening handover every day.
8. Access method
How the NOC reaches each environment: VPN, PAM, jump host. Good: named accounts, MFA, least privilege, revocable by you in seconds.
9. Vendor and carrier contacts
ISP support numbers, circuit IDs, account numbers, letters of authorization. Good: the NOC can open a carrier ticket without waking anyone.
10. Approval boundaries
What the NOC may do alone, what needs approval, and what's never allowed overnight. Good: written as explicit "may / must ask / never" lists.
11. Ticket standards
Categories, priorities, required fields, time entries. Good: a sample of a "perfect" overnight ticket.
12. Handover format
What your day team passes on in the evening, and what the NOC reports in the morning. Good: a fixed template both sides use every day.
What does a good NOC runbook template look like?
Every runbook should answer the same seven questions. Here's an example for a common overnight alert:
| Field | Example: "WAN1 down at a branch with LTE backup" |
|---|---|
| Trigger | WAN1 interface down > 3 minutes on a branch firewall |
| Scope | Branch sites with configured LTE / 5G failover |
| Checks | Confirm failover active, test reachability of core services, check the carrier status page |
| Allowed actions | Open a carrier ticket with the circuit ID, bounce the WAN1 interface once |
| Stop conditions | Failover not active, or LTE also down: escalate immediately |
| Escalation | P2 per matrix if the outage exceeds 2 hours, P1 if both links are down |
| Documentation | Ticket with timeline, carrier ticket number, current path; include in the morning report |
What are the most common documentation gaps?
- Escalation matrices that end with "call the owner" and no fallback.
- Carrier details that live in one person's email inbox.
- Runbooks that say "fix the issue" instead of listing allowed actions.
- No written list of what must never be done overnight.
Not sure how far along you are? The fit check includes a documentation question and tells you what to expect from onboarding. For the bigger picture, read the outsourced NOC buyer's guide.
Frequently asked questions
What if our runbooks are incomplete?
That's normal. A good NOC provider reviews what exists, flags the gaps, and helps turn tribal knowledge into written runbooks during onboarding, before go-live.
How long should a NOC runbook be?
As short as possible while still being unambiguous: one trigger, the checks, the allowed actions, the stop conditions, and who to escalate to. Most fit on one screen.
Who owns the runbooks after outsourcing?
You do. The NOC suggests additions after each out-of-runbook escalation, but your team approves every change.
Your next step
Your clients' outages fixed at 3 AM. You stay asleep.
Take the 2-minute fit check and see whether senior-led, runbook-first overnight NOC coverage fits your MSP, and which plan makes sense.
Start the fit check