Linux servers rarely fail loudly. They fail quietly: a disk that fills over three weeks, a certificate that expires on a Saturday, a patch nobody tested. Most teams do not need a full-time system administrator, but they do need someone accountable for these things. This guide is a practical checklist for choosing that someone.
Decide what you want covered first
“Linux support” can mean very different things. Write down which of these you expect a provider to own, which you will keep in-house, and which are shared:
- Operating system patching and upgrades
- The application stack on top (web server, runtime, database)
- Security hardening and access control
- Monitoring, alerting and log management
- Backups and, just as important, restores
- Incident response outside office hours
Twelve questions to ask a provider
- Which distributions and versions do you support? Ask specifically about the ones you run, including older releases that are near end of life.
- How will you access our servers? Look for individual named accounts, key-based login, least privilege, and an audit trail. Shared root passwords are a red flag.
- What happens when something critical breaks at 2 a.m.? Get coverage hours and response targets in writing, in your time zone.
- How do you handle patching? You want a clear policy: what gets patched, how it is tested first, and when downtime is announced.
- Who tests our backups? A backup that has never been restored is a hope, not a plan. Ask for restore tests and proof of the result.
- What do you monitor, with which tools, and who owns them? Make sure you can keep the dashboards and alert rules if you leave.
- What documentation do you produce? Runbooks, diagrams and change records should belong to you.
- What security baseline do you apply? Reasonable answers reference a recognised hardening standard and a way to check drift.
- Do you write root-cause notes after serious incidents? Repeat incidents are a cost; a short written cause and fix prevents them.
- How do we leave? Ask what the handover looks like. A good provider makes leaving easy and does not need lock-in to keep you.
- How is the work priced? Per ticket, monthly plan, or project. Understand what is included and what triggers extra cost.
- Who is my named contact? You should know who is accountable, not just which queue your email goes to.
Red flags
- Vague promises such as “fast response” with no written targets
- Reluctance to explain how they access your servers
- No restore testing, or no evidence of it
- Documentation that stays on their side
- Pressure to sign a long contract before they have seen your environment
A sensible way to start
Begin with a small, bounded piece of work, such as a health check of your servers or a handful of tickets, before committing to an ongoing plan. You learn how they communicate, how careful they are, and whether the answers above hold up in practice.
If you want to see how we work, read about our Linux server administration and support, or raise a ticket and describe what you need.