A hosting uptime SLA is a contract, not a promise that every request will succeed. This guide explains how to read availability definitions, measurement methods, exclusions, support commitments, and service-credit rules so you can compare providers consistently and know what to check before renewal, migration, or a vendor review.
Overview
A hosting service level agreement (SLA) defines the service a provider commits to deliver and the remedy available if it falls short. In a data centre or hosting contract, the headline uptime percentage is only one part of that commitment. The definition of “available”, the measurement point, planned-maintenance rules, incident exclusions, claim deadline, and credit limit can have a greater practical effect than the advertised figure.
Start by identifying exactly what the SLA covers. A provider might guarantee network connectivity, power delivery, a virtual machine, a dedicated server, a managed application, or a broader cloud service. These are different commitments. A colocation SLA may cover the facility’s power and network infrastructure while leaving your equipment, operating system, application, and upstream carrier outside its responsibility. A managed hosting SLA may include server monitoring or support response times, but not guarantee the performance of your database or third-party integrations.
Availability also does not equal performance. A server can respond while running slowly, returning errors, or failing health checks that the provider does not use for its SLA calculation. For a useful hosting SLA comparison, read the definitions before comparing percentages.
What to track
1. The service and measurement point
Record the precise service identifier covered by the contract: account, server, virtual machine, port, power feed, load balancer, region, or application tier. Then find where availability is measured. Possible points include the provider’s edge network, a facility router, a server interface, an internal hypervisor, or an external monitoring location.
A measurement taken inside a data centre may not show a routing problem between the provider and your users. Conversely, an external check may record an outage caused by your DNS, firewall, application, or access network. Neither method is automatically better; the important issue is whether it reflects the failure users and your operations actually care about.
2. The calculation period and definition
Check whether uptime is calculated monthly, across a billing cycle, or over another stated period. Look for the formula and the events counted as downtime. Some terms measure continuous connectivity; others require failed probes, an unreachable service, or a specific error condition for a defined interval.
Do not translate an uptime percentage into a guarantee without reading the calculation. An illustrative figure can be useful for planning, but its practical meaning depends on the length of the measurement period and how interruptions are rounded. Ask the provider to show how a short interruption, repeated packet loss, a partial regional failure, and a service that responds with errors would be classified.
3. Planned maintenance and exclusions
List every exclusion in a comparison worksheet. Common categories to investigate include announced maintenance, emergency maintenance, customer-caused incidents, configuration changes, exceeded resource limits, suspension for non-payment, abuse-related action, force majeure, third-party networks, and failures in software or equipment that the provider does not manage.
Pay particular attention to notice requirements and maintenance windows. An exclusion may apply only when the provider gives notice through a specified channel and completes work within a defined window. If the wording allows broad or undefined emergency maintenance, ask how it is recorded and whether there is a maximum duration.
4. Incident records and monitoring evidence
Find out which monitoring system is authoritative. The contract may rely on provider logs rather than your own monitoring, or it may require both parties to compare records. Capture the required evidence: timestamps in a particular time zone, monitoring graphs, ticket numbers, traceroutes, server logs, or screenshots. Establish whether an incident begins when your alert fires, when the provider detects it, or when the provider confirms it.
Run independent checks even when the SLA uses provider monitoring. External probes from relevant user regions, synthetic transactions, DNS checks, and application-level health checks help you distinguish network reachability from real customer availability. Keep these records for trend analysis and for any credit claim, while recognising that independent monitoring may not override the contract’s official measurement method.
5. Credits, claims, and limits
Service credits are usually a contractual remedy rather than compensation for every business consequence of an outage. Record the credit tiers, maximum credit, qualifying threshold, claim deadline, submission process, and any requirement for an account to be paid up. Check whether credits are automatic or must be requested.
Also review whether credits apply to a single affected service or the whole account, and whether they can be combined across multiple incidents. A low credit cap may make a headline uptime guarantee less meaningful for a business whose outage costs are substantial. If the SLA excludes consequential losses or limits liability elsewhere in the contract, escalate that language for legal review rather than assuming the service-credit table covers the risk.
6. Support and restoration commitments
An uptime SLA does not necessarily include a fix-time promise. Track separate commitments for support acknowledgement, escalation, status updates, replacement hardware, workaround delivery, and restoration. Distinguish response time from resolution time: an acknowledgement confirms that a ticket was received, while resolution means the service is usable again.
For dedicated server hosting, ask how hardware faults, spare parts, remote hands, and operating-system issues are treated. For VPS hosting, clarify whether noisy-neighbour events, host-node failure, migration, and storage failure fall under the same SLA. For cloud and hybrid hosting, check whether the commitment applies per instance, zone, region, or service, and whether your own redundancy design is assumed.
| Hosting model | Clauses to examine closely | Questions to ask |
|---|---|---|
| VPS | Host-node availability, storage, network, maintenance, resource contention | Is the guarantee per virtual machine or host platform? How are migrations and degraded storage measured? |
| Dedicated server | Power, network, hardware replacement, remote hands, customer-managed software | Does the SLA cover only facility connectivity, or also hardware repair and operating-system recovery? |
| Cloud hosting | Service scope, zones and regions, dependency failures, redundancy assumptions | Is availability calculated per resource, service, zone, or account? What architecture must the customer deploy? |
| Colocation | Power feeds, cooling, facility access, cross-connects, carrier services | Are your equipment, carriers, cross-connects, and remote-hands work included or excluded? |
Cadence and checkpoints
Review the SLA before signing, then create a small recurring control rather than relying on memory. During procurement, compare each provider using the same worksheet: covered service, measurement point, calculation period, exclusions, maintenance notice, support targets, credit tiers, claim process, liability limits, and termination rights.
After deployment, review availability and incident records monthly or at least quarterly. Match provider reports against your monitoring, ticket history, release calendar, maintenance notices, and customer-impact notes. Record near misses as well as qualifying outages: repeated packet loss, storage latency, failed backups, or delayed support may reveal operational risk that the formal uptime calculation does not capture.
At each checkpoint, confirm that the deployed architecture still matches the contract. A move to another region, a new load balancer, an added carrier, a changed backup design, or a different support plan can alter which SLA applies. Keep the current contract version and effective date with the review record.
How to interpret changes
A change in the reported uptime percentage should trigger investigation, not an automatic provider switch. First separate a genuine availability trend from a change in monitoring, service scope, or calculation rules. Ask whether the provider changed its status page, probe locations, maintenance policy, incident classification, or contract wording.
Then classify the operational effect. A single short outage may be less important than recurring failures during peak traffic, slow support escalation, or an incident that exposed a missing dependency. Compare the provider’s report with your own user-impact data, including failed transactions and affected regions. For low-latency hosting, a service can meet a broad uptime target while a connectivity problem in one important market still harms users.
Interpret credits separately from reliability. A credit may confirm that a contractual threshold was missed, but it does not restore lost data, missed orders, or engineering time. Use the result to improve your architecture: backups, health checks, multi-zone deployment, a second carrier, failover testing, or a documented migration plan may reduce exposure more effectively than negotiating a slightly higher percentage.
If wording becomes less precise, request written clarification before renewal. Terms such as “unavailable”, “maintenance”, “service”, and “network” should have operational definitions. Where the workload is regulated or has data-residency requirements, review the SLA alongside security, backup, incident-notification, and data-location terms rather than treating uptime as a complete risk assessment.
When to revisit
Revisit this hosting uptime SLA checklist before every renewal, migration, material architecture change, or major contract amendment. Perform a formal review at least annually and a lighter monthly or quarterly check of uptime records, exclusions, support performance, and open credits. Update your comparison whenever a provider publishes revised SLA wording, changes service tiers, adds regions, alters maintenance procedures, or changes its monitoring and claim process.
Use this practical sequence:
- Download the current SLA, order form, acceptable-use terms, and support policy.
- Mark the exact services and locations your account uses.
- Record the availability formula, exclusions, maintenance rules, and authoritative monitoring source.
- Compare provider incident records with independent monitoring and customer-impact notes.
- Check whether credits were claimed correctly and whether their cap matches your risk.
- Test one realistic failure scenario, including escalation, backup recovery, and failover.
- Assign an owner and next review date, and retain the document version used.
A reliable hosting decision depends on more than an uptime figure. By tracking what is covered, how failure is measured, what is excluded, and what remedy is available, you can compare VPS, dedicated, cloud, and colocation contracts on terms that match your actual workload.
