You’re paying for “managed infrastructure.” Or at least, that’s what the vendor said during the sales process. Here’s a simple test.
It’s 3 AM. Something breaks. Answer five questions:
- Who gets the initial alert? Your engineer, or theirs?
- Who triages? Your team deciding severity and priority, or theirs?
- Who diagnoses? Your engineer running queries at 3 AM, or theirs?
- Who remediates? Your team applying the fix, or theirs?
- Who runs the post-mortem and feeds improvements back into the system? Your team, or theirs?
If any of those answers is “our team,” your infrastructure is not managed. It is monitored. The vendor has given you eyes on the system. They have not given you hands, judgment, or accountability.
What Each Answer Reveals
Question 1: Who gets the initial alert?
If your team: You’re paying for monitoring. The tool detects problems. Your people deal with them.
If their team: First sign of actual management. But this alone isn’t enough — you need to check the remaining four questions.
The gap: Many “managed” services forward alerts to your Slack channel with a note attached. That’s monitoring with commentary, not management. The alert lands in your team’s lap. The decision about what to do with it is still yours.
Question 2: Who triages?
If your team: You’re deciding what matters. That requires context, judgment, and someone awake enough to make a good decision at 3 AM.
If their team: They’re making the severity call. They know which alerts are real and which are noise because they’ve been tuning this system continuously.
The gap: Triage is where most “managed” services stop. They tell you it’s important. You figure out what to do about it. That’s a consequential difference at 3 AM, when the person making triage decisions is operating on four hours of sleep and partial context.
Question 3: Who diagnoses?
If your team: Your engineer is running queries, checking logs, correlating events. At 3 AM. While half-asleep.
If their team: A senior engineer who’s seen this pattern before — across your system and across similar systems — is already investigating. They have context that a single-company team can’t accumulate.
The gap: Diagnosis requires deep system knowledge. A vendor that can detect but not diagnose is selling a smoke alarm, not a fire department. Detection without diagnosis is a notification, not a service.
Question 4: Who remediates?
If your team: Your engineer applies the fix. Your team owns the risk of the remediation itself.
If their team: They fix it. They’ve done this before. They have runbooks, automation, and the authority to act without waiting for approval from someone who’s still waking up.
The gap: Remediation is where the stakes are highest and where most vendors’ responsibility ends. They can tell you what’s wrong. You fix it. That boundary is the difference between a dashboard and a service.
Question 5: Who runs the post-mortem?
If your team: You analyze what happened and decide what to change. If your team has time. If the sprint allows it. If someone remembers to schedule it.
If their team: They analyze, document, and feed improvements back into monitoring, alerting, and runbooks — so this specific failure is less likely to recur. The system gets better because someone is accountable for making it better.
The gap: Post-mortems are the improvement engine. Without them, you’re not getting better — you’re just fighting the same fires with increasing fatigue. Alert fatigue is a management problem, and it compounds when nobody closes the loop.
The Three Tiers, Revisited
Where your answers place you:
| Tier | Your Answers | What You Have |
|---|---|---|
| Tool | All five answers are “our team” | A monitoring tool. You own every outcome |
| Managed Tool | Questions 1–2 are “their team” | Someone else detects and triages. You diagnose, fix, and improve |
| Managed Function | All five answers are “their team” | Someone else owns the entire operational loop — from detection to improvement |
This taxonomy isn’t new — it’s the same responsibility boundary that defines whether you bought a solution or bought more work.
The honest assessment: Most infrastructure services that call themselves “managed” operate at Tier 2 — managed tool. They alert you, sometimes triage for you, and leave the rest to your team. That’s legitimate, but it’s not the same as managing the function.
What Tier 3 requires: A provider willing to carry the pager, diagnose at 3 AM, remediate, and run the post-mortem. That’s an operational commitment, not a product feature. It requires a fundamentally different business model — one where the provider’s incentives are aligned with your outcomes, not just your data ingestion volume.
Using This Framework
How to apply the 3 AM Test:
To your current vendors: Ask them directly. “When something breaks at 3 AM, what happens on your side? Walk me through the five steps.” Their answer will place them on the tier chart. If they can’t answer clearly, that tells you something too.
To prospective vendors: Use it as an evaluation framework during sales conversations. Any vendor who can’t clearly articulate all five answers is selling you Tier 1 or Tier 2. That might be fine — but you should know what you’re buying before you sign.
To your own team: If all five answers are “us,” you’re not using a managed service. You’re using a tool and managing it yourself. That might be the right choice at your stage — but don’t confuse the two when budgeting, planning, or evaluating your on-call burden.
To your board: When asked about infrastructure management, the 3 AM Test gives a concrete, non-technical way to explain what you have vs. what you might need. Five questions. Clear answers. No jargon required.
Where This Leads
The 3 AM Test isn’t about whether your current setup is “bad.” It’s about knowing what tier of service you’re actually receiving — and whether that matches what you need.
Vigil by IOanyT is a Tier 3 managed function. We get the 3 AM page. We triage, diagnose, remediate, and run the post-mortem. Your team sleeps.
All five answers: “their team.”