Home · About · Services · Industries · Projects · Products · Process · Blog · FAQ · Contact
What server management services include, and what they should not The routine work a server management service should cover in 2026, where its boundaries sit, and the contract warning signs to check before you sign.
A common way to find out what your server management contract covers is to have an outage. The site is down, the disk is full of logs, and the provider replies that log rotation was never part of the agreement. Or the certificate expired, and it turns out nobody was watching it because the provider assumed the hosting company was.
Server management services cover the routine work of keeping a server secure, available and recoverable: security patching, monitoring with alerts that reach a person, backups with tested restores, access control and hardening, TLS certificates, disk and log housekeeping, and written documentation. They should not include owning your accounts, quietly changing your application, or vague promises in place of agreed response times.
This post sets out what a good service does each week and month, where the boundaries usually sit, and the warning signs to look for before you sign.
The core work: what should be included Whether the server is one VPS, a few cloud instances or a machine in your own office, the same jobs come up. A service that leaves out any of these is leaving a gap you will eventually fall into.
Patching. Security updates applied on a schedule, with kernel updates and the reboots they need planned rather than left pending for months. Operating system lifecycle. Tracking when your distribution leaves support and planning the upgrade well before then. Ubuntu 22.04 LTS, for example, leaves standard support in 2027, so servers still on it need an upgrade plan now. Monitoring and alerting. Uptime checks from outside the server, plus disk, memory, CPU and service health from inside, with alerts routed to someone who can act. Backups and restore tests. Databases, uploaded files and configuration copied off the server, and restored on a schedule to prove they work. Access and hardening. Key-based SSH, no direct root login, a firewall that only opens the ports you use, and a record of who has access. Web server and TLS. NGINX or Traefik configuration kept tidy, certificates renewing automatically, and expiry watched independently. Housekeeping. Log rotation, old Docker images and build artefacts cleared, and disk growth tracked before it becomes an incident. Documentation. What runs where, how to restart it, how to restore it, and who to call. Kept in your repository or wiki, not in one person's head. What a routine month looks like It helps to ask a provider to describe their cadence, because it shows whether the work is actually scheduled. A sensible cadence looks like this, adjusted to the system:
Daily: automated security updates, backup jobs, off-site copies and alert checks. Weekly: review of pending reboots, failed services, disk trends and the restore test results. Monthly: planned maintenance window for kernel reboots and non-security package updates, a review of user accounts and SSH keys, and a short written report. Quarterly: a full restore drill on a clean machine, a check of operating system and runtime end-of-life dates, and a review of firewall rules and open ports. Most of the daily work is automated. On Ubuntu and Debian, unattended-upgrades handles security updates. The part people forget is the reboot. The package is installed, but the running kernel is still the old one until the server restarts, so a server can be fully patched on paper and vulnerable in practice.
# Ubuntu / Debian: enable automatic security updates
sudo apt install unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades
# Is a reboot pending, and for which packages?
[ -f /var/run/reboot-required ] && cat /var/run/reboot-required.pkgs
# Which services have failed since boot?
systemctl --failed
# Disk usage by filesystem, and the largest directories under /var
df -h
sudo du -xh /var --max-depth=2 | sort -h | tail -15You can let unattended-upgrades reboot automatically at a fixed time, by setting Unattended-Upgrade::Automatic-Reboot "true" and Automatic-Reboot-Time in /etc/apt/apt.conf.d/50unattended-upgrades. That suits stateless web servers behind a load balancer. For a single server running a database, we prefer a planned window that someone watches, so a service that fails to come back is noticed within minutes rather than at the next morning's support ticket.
TLS certificates need more attention in 2026 Certificates used to be a set-and-forget item. Two changes make them a real part of server management now. Let's Encrypt stopped sending expiry reminder emails in 2025, so if renewal breaks, nobody is warned unless you monitor it yourself. And the CA/Browser Forum has agreed to shorten maximum certificate lifetimes in steps: 200 days from March 2026, 100 days from March 2027 and 47 days from March 2029. Anything still renewed by hand, such as a purchased certificate on an internal system, will need renewing far more often.
A good service makes renewal automatic and checks expiry from outside, separately from the tool doing the renewing:
# Certbot: confirm renewal would succeed without changing anything
sudo certbot renew --dry-run
# Reload NGINX after every successful renewal (deploy hooks run automatically)
printf '#!/bin/sh\nsystemctl reload nginx\n' | sudo tee /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh
sudo chmod +x /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh
# Expiry date of the live certificate, as a visitor sees it
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
| openssl x509 -noout -enddate
# Exit non-zero if it expires within 14 days (useful in a monitoring check)
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
| openssl x509 -noout -checkend 1209600The external check matters because a common failure is not the renewal itself. It is the renewed certificate sitting on disk while the web server keeps serving the old one, because nothing reloaded it. A deploy hook fixes that, and the external check proves it.
What server management should not include Some things are missing from weak contracts. Others are present and should not be. These are the ones we would push back on as a buyer.
The provider owning your accounts. The cloud account, domain registrar, DNS and backup storage should be in your organisation's name, with the provider given access. If the relationship ends, you should not need their cooperation to keep running. Shared or undocumented root credentials. Each person should have their own named account and key, so access can be removed individually and actions can be traced. Unrecorded changes. Configuration edited by hand on the server with no ticket, commit or note. Every change should leave a trail you can read later. Application changes slipped in as maintenance. Patching the operating system is server management. Changing your code, upgrading your framework or altering your database schema is development work, and it should be agreed and tested as such. Monitoring that only emails a shared inbox. An alert nobody reads is the same as no alert. Ask who receives it, and within what time they respond. Round-the-clock promises without detail. Coverage hours and response times should be written into the agreement with clear definitions, not implied by a word on a sales page. Compliance by assertion. A provider can apply practices that help with an audit, such as access reviews, encrypted backups and logging. It cannot make your system compliant on its own, and should not say it does. Where the boundaries usually sit Most disputes come from the grey area between the server and the application. It is worth agreeing these lines in writing before the first incident.
The server is up but the application returns errors: the provider should diagnose far enough to show whether the cause is the server, and hand over with evidence if it is the code. The database is slow: checking resources, connections and disk I/O is server work. Rewriting queries or adding indexes is usually application or database work, unless the contract covers it. A dependency in a Docker image has a known vulnerability: updating the base image may be in scope. Rebuilding and retesting the application usually is not, unless the provider also runs your deployments. A traffic spike: scaling within the agreed setup is in scope. Redesigning the architecture is a project. None of these answers is the only correct one. What matters is that they are written down, so a 2 a.m. incident is not spent arguing about whose job it is.
Questions to ask before you sign Which operating systems and versions do you support, and how do you handle end-of-life? How are security updates applied, and how are reboots scheduled? Where do backups go, how long are they kept, and when did you last restore one? Who receives alerts, during which hours, and what are the agreed response times? How do you record changes, and where can we see them? What do we receive if the contract ends: credentials, documentation, configuration? What is explicitly out of scope, and how is out-of-scope work agreed and priced? A provider who answers these clearly, with examples from their own process, is usually doing the work. One who answers with uptime figures and adjectives may not be.
A short checklist Security updates run automatically, and pending reboots are reviewed weekly. Each server has a known end-of-support date and an upgrade plan. Alerts reach a named person within agreed hours. Backups live off the server and are restored on a schedule. Certificates renew automatically and expiry is checked from outside. Accounts, DNS and backup storage are in your organisation's name. Every change is recorded, and the runbook lives where you can read it. If you can tick all of these, your servers are probably in good hands, whoever looks after them. If several are unclear, that is the place to start, either with your current provider or with a short audit of what is actually running.
Infigini IT Services · 11 Kanwali Road, Dehradun 248001, India · info@infigini.com · +91 95684 87789