A dedicated server can have the right CPU, enough memory, and a fast network connection—and still be a poor fit if nobody knows what happens during an outage. Before you rent, evaluate the service level agreement (SLA) alongside the hardware specification.
Start with three questions: what exactly is covered, when does the provider’s obligation begin, and who is responsible for getting your application back online? An uptime percentage alone cannot answer them.
- What does a dedicated server SLA cover?
- Translate uptime percentages into minutes
- Separate response, repair, and recovery
- Confirm who owns each recovery task
- Evaluate support outside business hours
- Read the credit rules before you need them
- Questions to send before renting
- Choose support that fits your recovery plan
What does a dedicated server SLA cover?
An SLA describes defined service commitments and the consequences of missing them. Read it together with the support scope for the exact server range, region, and support plan you intend to order.
For example, the OVHcloud US dedicated server SLA defines unavailability around loss of external connectivity and starts its downtime clock when the customer creates a support case. It also specifies claim deadlines and exclusions. This illustrates why your own outage timeline and the provider’s SLA timeline may differ.
Ask the provider to identify the document that applies to your quote. A cloud VM SLA, a managed hosting agreement, or a different country’s terms should not be used as a substitute.
Translate uptime percentages into minutes
For a simple 30-day month containing 43,200 minutes, the following figures show the downtime mathematically corresponding to each availability percentage.
| Availability | Equivalent downtime in 30 days |
|---|---|
| 99.9% | 43 minutes 12 seconds |
| 99.95% | 21 minutes 36 seconds |
| 99.99% | 4 minutes 19.2 seconds |
| 99.999% | 25.92 seconds |
Calculation: 43,200 × (1 − availability ÷ 100). These are arithmetic examples, not a forecast of actual outages or a guarantee of maximum incident duration. The applicable agreement determines the measurement period, exclusions, rounding, and eligibility for a remedy.
Use these figures to challenge your recovery plan. If a single restore takes two hours, a higher infrastructure availability commitment does not make that restore faster.
Separate response, repair, and recovery
When evaluating support, ask for separate definitions of these milestones:
- Initial response: when a qualified person acknowledges and begins handling the incident. Ask whether an automated reply counts.
- Diagnosis: when the fault is identified and a course of action is agreed.
- Hardware replacement: when the failed component is replaced. Ask whether the clock starts at incident reporting or only after hardware failure is confirmed.
- Service restoration: when the covered service works again. Establish whether that means network access, a bootable server, or a functioning application.
Consider a failed system drive. Installing a replacement drive may complete the provider’s hardware work, while your team still needs to reinstall the operating system, restore data, and validate the application. Plan those stages separately.
Ask whether each stated time is a target or an enforceable commitment, and what happens when it is missed.
Confirm who owns each recovery task
Infrastructure support and application administration can have different boundaries. The OVHcloud US Statement of Support, for example, distinguishes hardware and network assistance from customer responsibilities such as software maintenance and data restoration.
Before ordering, assign an owner to each task in your own recovery plan:
- Detect an outage and open the provider incident.
- Diagnose network reachability and inspect hardware.
- Approve a reboot, rescue operation, or component replacement.
- Rebuild the operating system and restore application data.
- Check data consistency and reopen traffic.
- Communicate with customers and document the incident.
If you are still deciding who should manage the server, read Managed vs Unmanaged Dedicated Servers: Which Should You Rent? Then confirm the actual services included in your chosen plan.
Evaluate support outside business hours
Ask a concrete question: “If our production server becomes unreachable at 02:00 on Sunday, which channel should we use, who receives the incident, and what happens next?”
Request the critical-incident procedure, severity definitions, escalation contact, and expected update frequency. Verify that more than one authorized person on your team can open an incident. Keep the instructions somewhere accessible if your own server is offline.
A useful pre-sales check is to submit a short technical question about recovery responsibilities. Evaluate the clarity of the answer, while recognizing that one sales interaction cannot establish future incident performance.
Read the credit rules before you need them
In the OVHcloud US example above, credits apply to future invoices, are capped, and require a request within 60 calendar days. The provider’s records determine validated unavailability. Those details matter as much as the headline percentage.
For your shortlisted offer, record the claim deadline, required evidence, exclusions, credit cap, and applicable fee base. Keep monitoring timestamps and incident references in a shared incident log. Treat any potential credit separately from your operational recovery budget.
Questions to send before renting
- Which SLA and support plan apply to this exact server and location?
- What condition counts as unavailable, and when does measurement begin?
- How are planned maintenance and partial network failures handled?
- What are the critical-incident response and hardware replacement commitments?
- Which recovery steps are included, and which require paid assistance?
- How do we escalate an incident outside business hours?
- What evidence and deadlines apply to a service credit request?
- Who restores our data after a drive or complete server replacement?
Choose support that fits your recovery plan
Define the interruption your workload can tolerate, then map the people and steps required to recover it. A development server that can be rebuilt tomorrow has different needs from a production database that must recover quickly.
For critical workloads, evaluate tested backups, spare capacity, and failover alongside support. Document the process in your deployment checklist; if moving from another host, include provider escalation contacts in your migration plan.
Before paying, make sure every recovery task has an owner and every support promise has a clear definition. That is what turns an SLA from a marketing figure into something your team can use during an incident.
