Most articles on this subject are written by companies selling managed hosting, and they arrive at the same conclusion by the same route: describe some disasters, imply they are imminent, present the retainer.
We sell managed support. We also think a substantial number of businesses should not buy it, and that a framework is more useful than a warning.
First, know where the boundary actually is
This catches people out more than anything else on this page.
On an unmanaged VPS, your provider is responsible for the hardware, the network and the hypervisor. Everything inside the virtual machine is yours: the operating system, the packages, the configuration, the application, the backups, the certificates.
“Managed hosting” from a provider usually means something narrower than the name suggests. It often covers the operating system to some degree and rarely covers your application, its dependencies, its backups or its certificates.
Read what your provider actually commits to in writing. Then look at the gap. That gap is the thing under discussion, and a surprising number of businesses have never identified it.
The six questions
Answer these honestly. The pattern of answers tells you more than any individual one.
1. What does an hour of downtime cost you?
Not a feeling. An estimate you could defend.
A local services business whose site generates a handful of enquiries a week can be down for four hours on a Sunday and lose very little. A store taking orders continuously loses revenue by the hour, plus the customers who conclude the site is unreliable.
If the honest answer is “not much,” that is a legitimate finding, and it should reduce what you spend here rather than being argued away.
2. Is there someone who could handle it, and is that a good use of them?
Two different questions.
Many small businesses have a technically capable person: a developer, a founder with a background in it, a competent generalist. They can patch a server.
The question is whether that is the best use of their time, and whether it will actually happen. In our experience server maintenance handled by someone whose main job is something else gets done enthusiastically for two months and then not at all. Not through negligence. It is simply never the most urgent thing on any given day.
3. What happens if that person is unavailable?
On holiday, ill, or gone.
If the answer involves finding a password nobody has, or a service nobody else has logged into, that is a concentration risk that exists whether or not you address it today.
4. When did you last restore a backup?
Not “do you have backups.” When did you last restore one and confirm the data was complete?
If the answer is never, you do not know whether you have backups. You have backup jobs that report success, which is a different thing. We have seen jobs report success for two years while producing an empty database dump.
This single question is the most reliable indicator we know of for how the rest of the answers will go.
5. Are your security updates current?
# Debian and Ubuntu
apt list --upgradable 2>/dev/null | grep -i security | wc -l
# Does this machine need a reboot to activate what is installed
[ -f /var/run/reboot-required ] && echo "reboot needed"If that number is large, or the reboot has been pending for months, updates are not being handled on a cadence. That is the mechanism behind most opportunistic compromises, which are not targeted at you specifically: a scanner finds a known vulnerable version and exploits it automatically.
6. Would you know if something were wrong before a customer told you?
Not whether monitoring exists. Whether an alert would reach a person who would act on it.
Alerting to an unread mailbox, or so noisy that the real alert is lost among routine ones, produces the confidence of monitoring without the benefit.
Reading the answers
Self-managing is a reasonable choice when:
- Downtime is genuinely low-cost for a few hours
- Somebody owns it as an explicit part of their role, not as an implied extra
- That person has a documented backup, in both senses
- You have restored from backup within the last six months
- Updates happen on a schedule you could describe
- Monitoring alerts reach someone who acts on them
If that is you, keep doing what you are doing. Adding a vendor buys you very little.
Managed support is worth the money when:
- Downtime costs real revenue, or customer confidence you would have to rebuild
- The capable person is expensive and their time is better spent elsewhere
- Knowledge concentrates in one person with no backup
- Nobody has restored a backup, or nobody is sure the backups cover everything
- Updates have slipped by months
- The server was inherited and is not documented
- You need to answer client or insurer questions about your hosting arrangement
The pattern to watch for is a set of individually reasonable answers that add up badly. The server works, someone could handle it, the backups probably run, updates are a bit behind. Nothing alarming in isolation. Together it describes a system nobody is actually watching, which is exactly the situation that produces an expensive week.
The middle options people forget
This is not a binary, and the middle is frequently the right answer.
A one-off audit and hardening pass. Someone documents what you have, fixes what is already broken, sets up monitoring and backups properly, and hands it over. You then maintain a system that is in a known-good state, which is much easier than maintaining one that is not. For businesses with a capable person and no documentation, this is often the highest-value option available.
Maintenance only, no support. Scheduled patching and backup verification, without an incident response commitment. Covers the slow-accumulating risk and costs considerably less than a support arrangement.
Escalation only. You handle the routine and have someone to call when something is beyond you. Works when the capable person is genuinely capable, and is a poor fit when they are not, because the call comes late.
Reduce the surface instead. Sometimes the right answer is not to manage the server better but to have less server. A static site on managed hosting has almost no operational burden. Not every business that ended up on a VPS needed one.
What it should honestly cost
We will not publish a rate card, because the same request can be a small monthly commitment or a substantial one depending on how many systems, how critical they are, and what state they are in.
What we will say is that the first month of any takeover is usually the largest, because there is a backlog: expiring certificates, failed backups, unpatched packages, a disk quietly filling. After that, a well-maintained single server is a modest ongoing cost, and if a provider’s ongoing figure is not modest you should ask what they are doing each month.
Be sceptical of two things: a price that seems low for the scope described, which usually means the scope is narrower than you think, and a monthly fee with no defined deliverable, which is a subscription rather than a service.
Three questions to ask any provider
“What did you do last month?” A good answer is specific: patches applied, a restore test performed, a certificate renewed, a disk trend noticed. A vague answer means nothing is happening on a cadence.
“What is not covered?” The arrangements that go wrong are the ones where nobody defined the boundary. Get it in writing before the first incident, not during it.
“What documentation do we keep if we leave?” If the answer is nothing, you are buying a dependency rather than a service. You should own the environment inventory, the procedures and the change history regardless of who maintains the server.
The honest summary
Plenty of small businesses manage their own servers perfectly well. They tend to have one thing in common: someone owns it explicitly, and that ownership survives that person being on holiday.
The businesses that get into trouble are rarely the ones that decided to self-manage. They are the ones that never decided anything. The server was set up, it worked, and nobody was ever made responsible for it.
If you take one thing from this: go and restore a backup this week. Whatever you decide afterwards, you will be making the decision with a real piece of information instead of an assumption.