What server management actually includes, and what it does not

“Managed” is one of the vaguest words in hosting. In one offer it means a script pings your server and emails you when it stops answering. In another, an engineer installs the kernel fix, picks a time to reboot and restores last night’s database when a migration goes wrong. Both are sold under the same word, and the difference only shows when you ask what is done, how often and by whom.

Patching: which updates, and who reboots

“We keep your server updated” can mean three different jobs:

• Security and package updates. The routine part. Ask how often: monthly, or sooner when something serious is published.
• Reboots. A new kernel takes effect only after a restart. A fix for a kernel flaw such as CVE-2026-31431 installs in seconds and protects nothing until the reboot, so someone has to choose when — and warn you first.
• Major upgrades. Debian 12 to 13, one Ubuntu LTS to the next. These are projects with a rollback plan: ask whether they are in the plan or quoted separately.

# if the newest installed kernel is not the running one, a reboot is pending
uname -r
ls /boot/vmlinuz-*

# AlmaLinux, Rocky Linux: exits with 1 and says so when a reboot is needed
dnf needs-restarting -r

Monitoring: an alert is only as good as who reads it

A ping check tells you the server answered a moment ago, not that the disk fills up on Tuesday or that the database stopped taking connections while the machine stayed up. Useful monitoring watches resources, disk health on physical hardware, the services that matter and the jobs that should have run.

Then ask what happens after the alert. Monitoring alone means you are notified and the fix is yours; with response, a person acts on it. An alert at 2 a.m. in a mailbox nobody reads until morning is a log entry.

Backups: the restore is the product

Nobody needs a backup; everyone needs a restore. Four things decide whether you have one:

1. Where it lives. A copy on the same disk or in the same data center goes down with the server.
2. How far back it reaches. A week of daily copies does not reach damage you notice on day ten.
3. What is in it. Database files copied mid-write may not start again; a database needs a dump or a snapshot it knows about.
4. Who tests restores, and how often. A backup nobody has restored is a hope.

# PostgreSQL: dump, then restore into a scratch database to prove it works
pg_dump -Fc -f app.dump appdb
createdb restore_test && pg_restore -d restore_test app.dump

Hardening: a baseline, not a shield

Hardening makes the defaults safe: SSH by key only, no direct root login, a firewall that drops everything not explicitly allowed, nothing listening that nobody uses. Ask to see it:

ss -tlnp                                                          # what is listening
sudo sshd -T | grep -E '^(passwordauthentication|permitrootlogin)' # what SSH enforces

It does not cover the code on top: a vulnerable plugin arrives on the very port the firewall exists to keep open.

Incident response: a reply is not a fix

The number in an offer is almost always the time to a first reply, not to a fix. Pin down three things:

• Which hours count. A Friday-evening ticket may get its first reply on Monday if business hours are weekdays only.
• What counts as critical. A fast round-the-clock response usually covers one defined case, such as the server being down or unreachable — not a slow page.
• Who talks to the data center. On a rented dedicated server disks and power supplies are physical; when one fails, someone has to read the RAID status, get the data center to replace it and watch the rebuild.

Where management ends: your application

The usual line is the operating system and the services on it. Your code, CMS, plugins, deploys and data are yours unless you buy that work separately. Most disappointment lives in the grey zone: a slow query, a CI pipeline, a move to a new server, cleaning up a hacked WordPress site. A good provider says in advance which of these is included and what the hourly rate is past that line.

Unmanaged is the other end: the provider keeps hardware, power and network running, hands you root and stops. Everything above, the 3 a.m. alert included, is yours — a fair deal when someone on your team already does this. A VPS with root access and nothing on top is cheaper for a reason: the cost of running it moves from the invoice to your calendar.

Questions to ask before you buy

1. Which updates are included, and who decides when the server reboots?
2. What is monitored, and does an alert lead to a person acting?
3. Where are backups stored, how long are they kept, and when was a restore last tested?
4. What is the first-reply time, in which hours, and what counts as critical?
5. Who deals with the data center when hardware fails?
6. Where does the service stop, and what is the hourly rate past that line?
7. When I leave, do you remove your access, and can I take my backups?

Each has a short, specific answer. A provider that will not write it down is telling you something.

The short version

Server management is a list of jobs, not a feeling of being looked after. Ask for each one in writing: the gaps in the answers are the work you will be doing yourself.