"Managed server support" means different things at different companies, and the gap between providers is usually not visible until something goes wrong and you discover what was never actually covered. Before comparing providers or signing an agreement, it helps to know what the term should include, what the common exclusions are, and which numbers in a sales page actually matter.
Monitoring: what should be watched, not just whether it is watched
Every provider advertises monitoring. The real question is what is monitored and how fast a problem becomes a human response rather than a silent graph.
A reasonable baseline includes host and service availability, CPU and load relative to core count, memory and swap activity, disk space and inode usage, backup completion, and certificate expiry. Monitoring that only checks whether the server responds to a ping misses most of the failure modes that actually cause downtime, such as a slowly filling disk or a backup that has silently failed for two weeks.
Ask specifically whether monitoring includes alert thresholds tied to a human response, or whether it is a dashboard someone is expected to check manually. The difference matters more than the list of metrics.
Response time: read the actual number, and what it applies to
A response time commitment, such as 30 minutes, only means something once you know what triggers the clock and what "response" actually means.
- Does the timer start when the alert fires, or when you open a ticket.
- Does "response" mean an engineer acknowledges the ticket, or that the engineer has started active diagnosis.
- Does the commitment apply equally at 3 a.m. as it does at 3 p.m., or is fast response a business hours benefit only.
A provider with a 15 minute response time that only applies during business hours is not meaningfully faster than a 2 hour commitment that genuinely holds at 3 a.m., if your real risk is an overnight outage.
Patching: whether it happens, and whether you find out
Security and package patching is one of the most commonly assumed but least consistently delivered parts of server management. Confirm whether patching is proactive, applied on a schedule without you asking, or reactive, applied only when you request it. Confirm whether kernel updates that require a reboot are included, since some providers patch userspace packages but leave kernel updates, and the reboot they require, entirely on the customer.
A patch applied without any record of what changed is also a real gap. Ask whether patch work is logged somewhere you can review, not just performed silently.
What "unlimited tickets" actually excludes
Unlimited ticket support is a common selling point, and it is usually true within a defined scope, not without limit. Unlimited support tickets typically cover operating system and server-level issues: service failures, performance problems, security incidents and configuration questions. It typically does not cover application development, custom code debugging, business logic changes inside your application, or hands-on work inside a CMS beyond basic troubleshooting.
The distinction that matters in practice: if a website is down because a server resource is exhausted or a service crashed, that is server management. If a website is broken because of a bug in custom application code, that is development work, and most server management agreements exclude it even when they advertise unlimited tickets.
Backups: configured is not the same as tested
Almost every provider includes backup configuration. Fewer providers include backup verification, confirming a backup can actually be restored, or backup monitoring, alerting when a scheduled backup silently fails. Ask specifically whether restore tests happen on any schedule, since an untested backup is a real risk disguised as a solved problem.
Security scope: patching is not the same as hardening
Security work under managed server support usually includes patching known vulnerabilities and basic firewall configuration. It does not always include proactive hardening, such as reviewing exposed services, auditing file permissions, or investigating brute-force patterns in authentication logs, unless the agreement specifically states it. If security hardening matters to your compliance requirements, confirm it is explicitly included rather than assumed.
How this differs across service tiers
Standard server management is usually built around a shared team responding to tickets and monitoring alerts for a single server. Higher tiers, such as proactive management, typically add faster response commitments and more active, scheduled maintenance rather than purely reactive work. A dedicated administrator model replaces the shared team with a named engineer, which matters once you are running enough servers that continuity and specific environment knowledge become valuable on their own.
None of these tiers is universally correct. The right one depends on how much unplanned risk you can tolerate and how much of the work you want handled proactively rather than only when something breaks.
What to actually ask a provider before signing
Ask what is monitored and what triggers a human response, not just an alert. Ask what response time commitment applies outside business hours, specifically. Ask what unlimited tickets excludes, in writing. Ask whether backups are tested, not just taken. These four questions surface most of the real differences between providers that otherwise look identical on a pricing page.
iServerSupport provides server management services with monitoring, patching, backup configuration and unlimited support tickets scoped clearly to server-level work, with proactive management and dedicated administrator tiers available once a single shared-team plan no longer fits.
Keep recurring server work off your team
Add monitoring, maintenance, security and troubleshooting for the infrastructure you already own or rent.
