Originally published at www.tothenoc.com
SLAs are contracts. What matters is execution.
Every NOC provider advertises response SLAs. "4-hour response." "1-hour critical response." "24/7 coverage." These numbers are easy to print on a website. What they mean in practice varies enormously — and you usually only find out when something is already broken.
I've been on both sides of this. As a senior NOC engineer handling emergency responses, and as someone who's had to clean up after a "guaranteed 4-hour response" that turned into a 14-hour outage. Here's what actually matters.
What "response" means — and what it doesn't
Read the fine print on any SLA. "Response" is almost never defined as "your problem is solved." It usually means one of three things:
Acknowledgment: We received your alert. A ticket has been opened. An automated email was sent. This is the weakest possible definition.
Initial triage: An engineer has looked at the alert and classified the severity. Still no guarantee of resolution timeline.
Active engagement: An engineer is actively working the issue. This is what you actually want.
When evaluating a NOC provider, ask explicitly: "When you say 4-hour response, does that mean an engineer is actively working my issue within 4 hours, or that I've received an acknowledgment?" The answer tells you everything.
What actually happens at 3am when a server goes down
A realistic sequence with a well-run NOC:
T+0:00 — Monitoring system detects anomaly (service timeout, disk full, interface down)
T+0:02 — Alert fires. If it's a transient spike, it clears and nothing happens. If it persists:
T+0:05 — Engineer is paged. Not a bot. Not a tier-1 filter. An engineer.
T+0:10 — Engineer is logged in, running diagnostics. Checks logs, service status, recent changes.
T+0:20 — Root cause identified in most cases (disk, process crash, network, application). Remediation begins.
T+0:45 — Service restored or escalation path activated if issue requires vendor involvement.
That's what good looks like. A 4-hour SLA means the engineer is engaged within 4 hours of the alert — not that resolution takes 4 hours.
Red flags in NOC SLA agreements
SLA credits instead of resolution commitments. "If we miss our SLA, you get a credit on next month's invoice." A credit is nice. It doesn't fix your 6-hour outage. Ask about resolution commitments, not just credit policies.
Tiered escalation with undefined timelines. Tier-1 responds in 1 hour, escalates to tier-2 in 2 hours, tier-2 escalates to tier-3… By the time someone who can actually solve your problem is on the call, you're 6 hours in. For SMBs, a flat escalation path to a senior engineer is worth more than a multi-tier SLA.
Exclusions buried in the contract. "SLA applies during business hours." "SLA excludes third-party service outages." "SLA excludes hardware failures." Read the exclusions before you sign.
No documentation of your environment. If the NOC doesn't have documentation of your specific infrastructure — topology, credentials, runbooks — their engineer is starting from scratch during your incident. That costs time you don't have.
What the ToTheNOC response SLA actually means
When a client in the NOC Command plan has an incident, the SLA is under 4 hours — but in practice it's usually under 15 minutes. Why? Because there's no tier-1 filter. The alert goes directly to me. I know the client's environment because I documented it during onboarding. I'm not reading a wiki to figure out what credentials to use.
The advantage of a boutique NOC isn't just the SLA number — it's the context. One engineer who knows your environment responds faster and more effectively than a staffed NOC where the overnight shift has never seen your infrastructure before.
Questions to ask any NOC provider before signing
What does "response" mean in your SLA — acknowledgment, triage, or active engagement?
Who specifically responds to my incident at 3am — tier-1, tier-2, or a senior engineer?
What documentation will you maintain about my environment?
What are the SLA exclusions?
Can I see a sample incident report from a past engagement?
What's your escalation path if the on-call engineer can't resolve the issue?
Alexandru Cazan is a senior NOC engineer with 25+ years of remote infrastructure experience. Learn more about NOC Response services or book a free technical call.
