What your hosting provider actually covers, and how to find out
Most businesses believe their hosting is looked after. A smaller number could say who applies the security updates, when a backup was last restored successfully, or who gets woken up if the site goes down at three in the morning.
The gap between those two positions is where outages turn into bad weeks. Closing it takes about half an hour and a handful of direct questions.
Managed is not a defined term
It is worth understanding why this is confusing. There is no standard behind the word.
At one end, managed means the provider keeps the physical hardware and the network running, and everything above that is your problem. Operating system, software, updates, backups, all yours. At the other end it means they handle the operating system, apply patches, take backups, monitor the service and will pick up the phone. Both are legitimately advertised as managed hosting, and the price difference reflects a genuine difference in what you are getting.
Neither is wrong to sell. It becomes a problem when a business assumes the second and has bought the first, which is common and usually only discovered during an incident.
The questions to send your provider
Put these in an email. You want the answers in writing, and how readily they answer is itself informative.
- Who applies operating system security updates, and how often? If the answer is that you do, you now know something important.
- Are backups taken, how frequently, and where are they stored? Backups on the same machine as the live site protect you from very little. Hardware failure or a compromise takes both.
- How long are backups kept? Some problems are not noticed for weeks. Seven days of retention will not help with a corruption that started a month ago.
- When was a restore last tested, and how long did it take end to end? This is the question that separates providers who take backups from providers who take backups that work.
- What are you monitoring, and who is notified? Monitoring that writes to a dashboard nobody has open is not monitoring in any useful sense.
- What is the response commitment outside business hours, and what does out of hours mean in your timezone?
- If the server is compromised, what do you do and what do I do?
You are not looking for perfect answers. Plenty of sensible arrangements involve you owning some of this. You are looking to know which parts are yours, so that nobody is assuming somebody else has it covered.
Untested backups are not backups
This deserves its own section because it is the single most common failure, and it is completely preventable.
Backups that run nightly and report success for two years can still be useless. The job might have been quietly excluding a directory since a configuration change. The database dump might be truncating. The files might be there and the restore procedure might take eleven hours, which is fine for an archive and not fine for a business that cannot trade while it runs.
None of that is visible until you try. So try. Restore to a separate machine, bring the site up, log in, check that recent records are present, and time the whole thing. Do it once, write down what happened, and repeat it twice a year.
The number you get is worth knowing on an ordinary Tuesday rather than discovering during an incident.
Decide how much downtime and data loss you can absorb
Two numbers, in plain language, agreed by whoever runs the business rather than whoever runs the servers.
The first is how long you could be offline before it becomes serious. An hour, four hours, a day. The honest answer varies enormously by business, and a company that takes orders online has a very different tolerance from a consultancy whose site is mostly a brochure.
The second is how much recent work you could stand to lose. If backups run nightly at two in the morning and the server fails at four in the afternoon, you have lost fourteen hours of everything. Whether that is an inconvenience or a catastrophe depends entirely on what happens in those fourteen hours.
Once you have both numbers, the technical decisions mostly answer themselves, and you can tell whether what you are currently paying for is over specified, under specified, or about right.
Patching, and why it stops happening
Security updates are dull, invisible when done, and only noticed when skipped. So they are the first thing to slip when everybody is busy.
The pattern is familiar. Updates get applied diligently for the first few months after launch. Then one update causes a problem, everyone becomes cautious, and a backlog forms. A year later the server is far enough behind that updating feels risky, which makes the backlog grow faster.
What prevents this is unexciting. A schedule, an owner, a place to apply updates before production, and an accepted maintenance window. It does not need to be sophisticated. It needs to be somebody’s actual job rather than something that happens when there is time.
Some of it is yours regardless
Even on a fully managed arrangement, a few things stay with you, and they are the ones most often neglected.
Application level updates are the clearest example. Your host may patch the operating system diligently and still have nothing to do with the content management system, plugins or themes running on top of it. That layer is where a large share of compromises begin, and it is frequently nobody’s named responsibility.
Access control is the other. Old administrator accounts belonging to former staff or previous agencies tend to survive for years. Review who has access twice a year, remove anybody who no longer needs it, and use separate accounts per person rather than one shared login, so that an audit trail exists when you need one.
Know where things live
One more piece of housekeeping that costs nothing and saves a great deal during a bad week.
Write down where the domain is registered and when it expires. Where DNS is managed. Where the certificate comes from and when it renews. Which email address the alerts go to. Who has administrative access, including anybody who has left.
Sites go down because a domain quietly expired far more often than anybody admits. And when a real incident happens, the first twenty minutes are frequently spent working out who controls what. Having that written somewhere other than one person’s memory turns those twenty minutes into two.
