What "24/7" should mean in a managed services contract
Almost every provider advertises round-the-clock support. Far fewer will tell you who is awake, what they are allowed to do at 3am, and what happens when the answer is "nobody, until Monday". Here is how to read the claim.
Every managed services provider in the country advertises 24/7 support. The phrase has been repeated so often that it has stopped carrying information. It appears on the website of firms with a genuine follow-the-sun rota, and on the website of firms where "24/7" means a voicemail box that a technician checks when they wake up.
The difference matters most at exactly the moment you cannot evaluate it — during an outage, at two in the morning, when you are already having the worst week of your quarter. So the evaluation has to happen now, in the procurement conversation, while there is time to ask awkward questions.
This is the set of questions we would want a prospective client to ask us, and the answers we think a serious provider should be able to give without checking.
Who is actually awake
There are four common arrangements behind the same two-digit claim, and they are not equivalent.
- A staffed desk. Named engineers on shift, at a console, taking work as it arrives. Response is measured in minutes because someone is already looking.
- An on-call rota. Nobody is at a desk, but a named engineer carries a pager, has agreed response targets, and is compensated for the disruption. Response is measured in tens of minutes.
- Best-effort escalation. Alerts route to a shared inbox or a group chat. Somebody usually sees them. Nobody is contractually obliged to.
- An answering service. A third party takes your call, creates a ticket, and tells you a technician will be in touch. The technician is asleep.
All four get described as 24/7. Only the first two are a commitment. Ask which one you are buying, ask it plainly, and ask for it in writing. A provider running a real rota will answer immediately, because they pay for it every month and they know exactly what it costs.
That 258-day figure is the one worth sitting with. It is not the time to fix a breach. It is the time to notice one and stop it. Coverage that only looks at your estate during business hours is, arithmetically, a contributor to that number.
What they are allowed to do at 3am
This is the question almost nobody asks, and it is the one that separates a provider who can end your incident from one who can only observe it.
An engineer woken at 3am needs three things to be useful: access, authority, and a runbook. If they have monitoring access but no ability to restart a service, they can tell you the site is down. If they can restart the service but need your CFO's approval to fail over to the standby, they will spend the outage trying to wake your CFO. If they have both but no documented procedure for your specific environment, they will be reading your infrastructure for the first time under pressure.
So ask: what is the standing authority at 3am? Ours is written down per client, and it usually looks something like this — restart any service on the allow-list without asking; fail over to standby without asking, with notification; restore from backup without asking if the alternative is extended downtime; make no change that alters data or spend without a named approver.
The point is not that our specific line is correct for you. The point is that there should be a line, you should have agreed to it in daylight, and the engineer should not be discovering it at 3am.
The gap between office hours and coverage
Here is a distinction that gets deliberately blurred, and we would rather be explicit about it than benefit from the confusion.
Our office is open 9:00 to 17:00 Mountain Time, Monday to Friday, and we close on U.S. federal holidays. That is when you reach a human about a contract, an invoice, a new project, a scheduling question, or anything else that is a business conversation rather than an incident.
Our help desk is staffed 24 hours a day, every day of the year, including the holidays the office is shut. Monitoring, escalation, and emergency response never stop.
Those are two different things and a provider should tell you both. When a firm advertises 24/7 and then takes three days to answer a billing question over Thanksgiving, they have not lied to you exactly — but they let you believe something convenient. The honest version is that incidents and admin have different clocks, and you should know which clock your question is on.
| Question | Which clock | Realistic response |
|---|---|---|
| Site or service is down | Help desk, 24/7 | Minutes |
| Suspected compromise | Help desk, 24/7 | Minutes, with escalation |
| User cannot log in | Help desk, 24/7 | Minutes to an hour |
| New user onboarding | Office hours | Same business day |
| Invoice or contract query | Office hours | Same business day |
| Project scoping | Office hours | Scheduled |
What the SLA actually promises
Read the definitions section before the numbers section. The numbers are meaningless without them, and the definitions are where the interesting drafting lives.
Response time is usually the headline, and it is the weaker of the two commitments. It means somebody acknowledged the ticket. An automated email that says "we have received your request" technically satisfies a fifteen-minute response SLA, and some providers rely on exactly that.
Resolution time, or a restoration target, is the commitment that matters, and it is the one most contracts avoid making. Where you do see it, check what stops the clock. If the clock pauses whenever the ticket is "waiting on customer", and the provider can set that status unilaterally, the target is decorative.
Severity definitions are where the real negotiation happens. If the provider alone decides what counts as Severity 1, then every incident is a Severity 3 until you escalate socially. Good definitions are objective and testable: a service is unavailable to all users; data loss is suspected; a security control has failed. Bad definitions are subjective: "critical business impact as determined by the provider".
The test that settles it
There is a simple way to find out what you have bought, and it costs one afternoon.
Ask your provider to schedule an unannounced out-of-hours test. Not a conversation about the process — an actual page, raised at an actual awkward hour, against a non-production system. Measure the time from alert to a human being engaged, and the time from engagement to the system being restored.
Providers who run a genuine rota will agree readily, because a test they pass is the best sales collateral they have. Providers who do not will find reasons why a test is not representative, or will want two weeks' notice, which defeats the point.
We run this against our own estate quarterly, and we will run it with a client on request. It is the only claim in this article that we would not expect you to take on faith.
The honest summary
24/7 is not a feature, it is a cost structure. Someone is being paid to be awake, or they are not. Rotas are expensive, they are difficult to staff, and they are the single largest line item in delivering genuine round-the-clock coverage. A provider whose price is substantially below the market for a fully-staffed desk is telling you something about their rota, whether or not they mean to.
That does not automatically make them the wrong choice. Best-effort coverage at a lower price is a legitimate product, and for some organizations it is the correct trade. What is not legitimate is selling best-effort at the price of staffed, and letting the client discover the difference during their first serious outage.
Ask the questions. Get the answers in the contract. And if a provider is reluctant to be specific about who is awake at 3am, treat that reluctance as the answer.
Autres publications
Least privilege without breaking everything
Removing local administrator rights is one of the highest-value security changes available and one of the most frequentl
Lire la suiteWhat an hour of downtime actually costs
The published averages are enormous and nearly useless, because they average across organizations nothing like yours. He
Lire la suiteInfrastructure as code for organizations that are not software companies
The practice is usually explained by software companies, to software companies, with examples from software companies. T
Lire la suiteEst-ce le bon choix pour vous ?
Nous qualifions chaque mission avant de la chiffrer. C’est un échange technique sur votre infrastructure, pas un appel commercial — et une réponse franche si nous ne sommes pas le bon cabinet.