Every managed cloud provider advertises 24/7 coverage. Almost none of them mean the same thing by it.
At one end, "24/7" means an alert fires at 3 AM, a system routes it to your inbox, and a human reads it when the business day starts. At the other end, it means an engineer is awake, holds a role in your account, has a runbook for the thing that just broke, and is authorized to act on it before you know anything happened.
Both are sold with the same two words on the same slide. The gap between them is the difference between finding out at 8 AM that you were down for five hours and finding out at 8 AM that you were down for eleven minutes, and it's already handled.
This is a guide to telling them apart: the four levels of 24/7 coverage that actually exist, how to tell which one you're being sold, and why the metric everyone leads with is only the start of the conversation.
Nearly every SLA in the market is built on first response time, and for good reason: it's the one commitment a provider can make honestly. Nobody can promise a resolution time. A misconfigured security group and a regional service degradation are not the same problem, and a provider who contractually commits to fixing both in ninety minutes is either padding the number into meaninglessness or writing a check they'll cover with an exclusion clause.
So the first response is the right thing to commit to; it should be fast, and it should be a human. The question is what happens on the other side of it.
A first response time tells you when someone starts. It doesn't tell you what they're equipped to do: whether they can see your environment, whether they have a runbook for this failure, or whether they're permitted to touch anything. Two providers can hit the same first-response number and be in completely different businesses.
Site reliability practice is clear about what matters once someone has responded. Google's SRE guidance puts the priority order plainly: "stop the bleeding, restore service, and preserve the evidence for root-causing." Mitigation first, permanent fix later. Which makes the question: what the responder is able to do in the hour that follows.
That has four possible answers.
A note on scope before the four levels. This is about alert-driven work: the pager fires on its own, at 3 AM, with nobody on your side awake to notice. That's a different motion from ticket-driven support, where you spot a problem and open a case. Support is table stakes and every serious provider bundles it. What separates them is what happens when no one has opened a ticket, because no one is awake.
Thresholds fire and the alert is routed to you. Nobody has looked at it.
Detection and delivery have real value, since you can't respond to what you can't see. But the entire cognitive burden stays with your team. At 3 AM, your engineer wakes to a raw alert with no context and no indication whether it's real.
The tell: the SLA describes notification times.
Someone is awake, sees the alert, and looks. False positive or real, correlated against other signals, relevant logs pulled, findings written up and handed to you with a recommendation.
A real step up. Cloud-native detection generates finding volumes that overwhelm unfiltered queues, so separating noise from signal is meaningful work. Your engineer gets woken only for things that are actually broken and arrives with a head start.
But the boundary is firm: they investigate, you remediate. The party with the context isn't the party with the permissions, so every fix waits for someone on your side to wake up and act.
The tell: ask whether they can change anything in your environment.
A clean no means Level 2.
The team investigates and acts within limits agreed in advance.
Restart the unhealthy service. Fail over to the standby. Scale the group. Roll back the deployment that correlates with the error spike. Each is pre-approved for a defined trigger, with anything outside that set requiring your approval in the moment.
This is where the model changes shape, because it requires a prior decision about what the partner may do without asking. Not a permissions checkbox, but a negotiation documented in runbooks. Read access is standing; write access exists only where a runbook says so or where you approve it live. That's what makes 3 AM autonomy safe: the authority is real and bounded by a document you wrote together, not by the judgment of whoever's on shift.
The tell: ask to see a runbook. It should be specific to your environment and name actions.
Everything in Level 3, plus the partner runs the incident: coordinating responders, managing communications, driving escalation, engaging the cloud provider on your behalf, and owning the case until the environment is stable.
The difference from Level 3 is coordination, not permission. Level 3 fixes what it's authorized to fix. Level 4 owns the incident, including the parts no runbook anticipated: when to escalate, who else to pull in, what to tell your stakeholders, and when it's genuinely over.
Google's incident management framework, based on the Incident Command System used for wildfires and earthquakes, exists for this reason. Someone has to coordinate, communicate, and control, and it shouldn't be the person elbow-deep in the terminal. Level 4 fills that role at 3 AM, so your VP of Engineering doesn't.
The tell: ask who declares the incident over.
Managed providers describe all four levels with similar language, which is how buyers end up believing they've bought Level 3 and discovering during their first real outage that they bought Level 1.
The jump from Level 2 to Level 3 is the hard one, and the reason is structural rather than commercial.
Levels 1 and 2 scale across customers. Detection, triage, and investigation are largely generic: a mature operations team can watch an environment competently without months of prior immersion in it. That's why monitoring can be delivered as a standalone tier, and for plenty of organizations, it's the right purchase.
Levels 3 and 4 can't work that way. Authorized actions require someone to have sat down with your team and decided, in advance, which actions are safe in your environment. Runbooks require knowledge of your architecture and dependencies. Escalation paths require knowing who on your side can approve an out-of-runbook action at 3 AM. Severity definitions require knowing what "business-critical" means for your business specifically.
None of that comes from a monitoring subscription. It comes from an MSP engagement, where the partner takes ongoing operational responsibility and does the design work before go-live.
So the practical rule: operational authority is earned through design work, not switched on by a signature. If a partner offers you 3 AM autonomy without proposing that design work, they're describing Level 2 in Level 3 language. And if you've bought monitoring while expecting someone to fix production overnight, you've bought investigation without authority.
Levels 3 and 4 can't be switched on. They require a working session before going live to establish six things.
Severity levels are tied to your business impact. Not generic P1 through P4. Adopting the cloud provider's own severity taxonomy is a shortcut worth taking, because when you escalate mid-incident, there's no translation step and no argument about whether this qualifies as production-down.
Runbooks per scenario. Start from the partner's defaults, since a mature MSP has a library covering failure modes that recur everywhere, then adapt to your architecture. The adaptation is the valuable part. Decide explicitly what happens when an alert arrives that no runbook covers, because it will. That path should lead to a human with authority, not a dead end.
Escalation paths that run in parallel. The common failure is sequential escalation: tier 1 tries for thirty minutes, hands it over to tier 2, which tries for thirty minutes, and two hours in, someone suggests calling the cloud provider. For business-critical incidents, the internal ladder and provider engagement should start together, right after the first triage. The cost of engaging the provider unnecessarily is trivial next to the cost of engaging them ninety minutes late. Lower severities can be worked internally first.
Authorized actions. The explicit list of what the partner may do without asking, and how anything else gets approved in real time.
Access model. Which roles, scoped how, assumed when, audited by what. Read-only standing access with defined exceptions is the target. Both extremes fail: too restrictive for the level you've bought, and the partner has full context they can't act on. Too permissive and you've handed standing production write access to a third party, which is a finding in your next audit and a blast radius problem the first time someone acts on a bad assumption.
Communication protocol. Who gets notified at what severity, through which channel, and who on your side can approve out-of-runbook actions at 3 AM. Naming that person in advance is one of the highest-leverage items in the whole document.
The AWS Well-Architected Framework makes the same argument: define in advance the personnel required to resolve an event, and include escalation processes to engage additional people as urgency and impact demand. If a partner can onboard you to Level 3 without covering these six, they're delivering Level 1 or 2, because Level 3 is these six.
Not every workload needs Level 3 or 4, and it's worth being skeptical of a partner who insists otherwise.
Levels 1 and 2 fit when you have a mature on-call rotation with real depth, the workload tolerates hours of degradation, or you want full operational control for compliance reasons. You've outgrown them when incidents regularly stall waiting for someone with permissions to wake up, when your engineers are getting paged for incidents that a runbook could have closed without them, or when senior people are burning out on after-hours work that builds nothing.
The real test: what does the difference between an eleven-minute outage and a five-hour one cost you? If it's material to your revenue, your customers, or your regulatory position, an investigation without authority isn't enough.
Cloud Monitoring covers Levels 1 and 2: continuous monitoring, human triage, investigation, and escalation to the cloud provider, on AWS and Google Cloud alike. Datadog is our NOC platform, with telemetry streaming in continuously, alerts correlated and enriched, and our operations center working the queue around the clock. Findings route into Jira Service Management for on-call dispatch.
The first response to critical production events is five minutes for a human. For calibration against the ticket-driven equivalents in the market, AWS Enterprise Support targets under 15 minutes for business-critical cases, and AWS Unified Operations targets 5 minutes from an Incident Management Engineer. We're at the fast end of that range, and the responder is already inside your environment with context loaded rather than starting from your description of the problem.
What happens next is the differentiator. For critical production incidents, we don't work the internal ladder first and call the cloud provider when we're stuck. Immediately after the first triage, we engage the cloud provider directly and work the incident shoulder to shoulder with their team, while our internal escalation ladder runs in parallel. Two paths, simultaneously, from the moment we've triaged. Non-critical incidents we handle in-house, bringing the cloud provider in when the investigation points to their side of the shared responsibility line or when a second set of eyes will close it faster.
Levels 3 and 4 come with our MSP program, which is a deliberate boundary rather than a packaging decision. Operational authority requires the design work described above, so for MSP customers taking NOC and SOC services, we run a working session before go-live covering all six: severity mapping, runbooks, escalation paths, authorized actions, the access model, and communication protocol, including the named person on your side who can approve an out-of-runbook action at 3 AM.
Access is read-only by default, with write access in exactly two circumstances: an action pre-authorized in a runbook we built with you, or an action you approve in the moment. That boundary is set during onboarding and doesn't move during an incident. At Level 4, we also take incident command, coordinating responders and owning stakeholder communications until your environment is stable.
Ticket-driven support runs alongside all of this. It's built into every engagement at no extra tier, and it's also available on its own. We don't commit to a time-to-resolution, for the reasons above, and the cloud provider's taxonomy.
This is the operational half of a pair. The security half, covering GuardDuty-based detection and AWS Security Incident Response with our engineers on your IR team membership, is in our Cloud SOC on AWS guide. And our autonomous support agent runs read-only and guardrailed ahead of the responder, so the engineer who picks up the case arrives at an evidence-backed diagnosis rather than a blank terminal.
Every cloud partner will tell you they offer 24/7 coverage. The words are free.
What isn't free is the structure underneath: a human awake at 3 AM with your environment's context, a runbook written for the thing that just broke, permission agreed in advance to act on it, and someone who owns the incident until it's over.
So the question isn't whether a partner covers you 24/7. It's this:
At 3 AM, when the alert fires: who investigates, who is allowed to fix it, and who owns it until my environment is stable?
Ask it in a sales conversation and listen for specifics. "We'd work with your team on that," with no runbook, no action list, and no named approver, is a Level 1 answer wearing Level 3 language. A partner operating at Level 3 will name the actions they're authorized to take and show you a runbook that contains them.
If the answer to who's allowed to fix it at 3 AM is still "we'd figure it out," that's the gap an MSP impact analysis is built to close. We map your environment, your access model, and your escalation paths before we ever touch production.
Request an MSP impact analysis.
Monitoring detects, triages, and investigates. An MSP program adds operational authority: the ability to act on what was found, within boundaries agreed in advance. The practical test is whether the party who found the problem is allowed to fix it.
It's a separate axis, not a rung on this ladder. Good support runs 24/7 and responds to critical cases at any hour, and it's included in every serious engagement.
The limitation isn't the provider's availability; it's the trigger. A ticket requires someone on your side to be awake, notice the problem, and open it. At 2 AM on a Saturday, your team isn't watching, so the incident sits until someone happens to look. Monitoring and MSP close that gap from the other direction: the environment is watched continuously, so the alert starts the response rather than the customer.
Rarely, because the blocker isn't commercial. Nobody can hand a partner safe write access to an environment they haven't mapped, and mapping it is the engagement. What you can do is start narrow: pick your two or three most common failure modes, build runbooks for those alone, and widen the authorized-action list as the partner earns context.
Because incidents aren't uniform. Time-to-fix for a misconfigured security group and for a regional provider degradation have nothing in common, so a single commitment covering both is either padded to absurdity or hedged with exclusions. First response can be committed to honestly. Resolution generally can't.
Standing unrestricted write access, no. Scoped pre-approved write access for defined actions under defined conditions is what makes a 3 AM response possible without waking your team.
Every managed cloud provider advertises 24/7 coverage. Almost none of them mean the same thing by it.
At one end, "24/7" means an alert fires at 3 AM, a system routes it to your inbox, and a human reads it when the business day starts.
Picture a meeting room. Laptops open, screens flickering, everyone with that particular gleam in their eye. The first word in the air isn't "hello," it's "AI." And then comes the moment that always arrives: someone says, with total confidence, "We want ChatGPT. But ours. Now."
Most conversations about MSP vs. in-house cloud operations begin with the wrong question.
Companies ask whether they should manage their cloud internally or hand it over to a managed service provider, as though one side needs to own the entire environment.
