What an SLA at a data center actually means
An SLA (Service Level Agreement) is the data center's written commitment to infrastructure availability: power, cooling, and network. In a dedicated server contract the SLA is usually expressed as a percentage, for example 99.9% or 99.99%, and tied to a financial credit for downtime beyond the limit.
The availability percentage alone tells you little until you convert it into hours and minutes of downtime per year. Below we show how to do that and what to check first in a data center SLA.
Tier I-IV levels: what is the difference
The Uptime Institute classification splits data centers into four tiers based on redundancy of engineering systems: power, cooling, and connectivity inputs.
| Tier | Redundancy | Guaranteed availability | Downtime per year |
|---|---|---|---|
| Tier I | No redundancy | 99.671% | 28.8 hours |
| Tier II | N+1 | 99.741% | 22.0 hours |
| Tier III | N+1, maintainable without shutdown | 99.982% | 1.6 hours |
| Tier IV | 2N+1, fault tolerant | 99.995% | 0.4 hours |
Providers rarely state the Tier explicitly in marketing, but almost always publish the SLA percentage — it reveals the real level of power redundancy, which is covered in a separate article.
How much downtime that is in minutes
Converting a percentage into an absolute number is simple: (100% − SLA%) × minutes in a year.
| SLA | Downtime per year |
|---|---|
| 99% | 3.65 days |
| 99.9% | 8.76 hours |
| 99.95% | 4.38 hours |
| 99.99% | 52.56 minutes |
| 99.999% | 5.26 minutes |
The gap between 99.9% and 99.99% is the difference between a full workday of downtime and a single lunch break. For an online store or billing system that difference matters.
What a data center SLA does not cover
A data center SLA covers the building infrastructure and the link up to your rack. It does not cover:
- Operating system and application failures on the server itself.
- A failed drive or memory module inside your own hardware.
- Configuration mistakes made by the server administrator.
- Application-layer DDoS attacks — a separate protection layer handles those.
A high SLA percentage from the data center does not remove the need for monitoring the server itself and backing up its data.
How to check server availability yourself
Do not rely only on the provider's reports — keep an independent uptime record.
uptime
# 10:14:02 up 214 days, 3:41, 2 users, load average: 0.12, 0.09, 0.05
For external checks use a third-party availability monitor polling every 30-60 seconds with an alert to a messenger. This complements hardware monitoring over IPMI, which watches temperature, drives, and power inside the server itself.
Checklist before choosing a data center
- Get the stated Tier and SLA percentage in writing, not just verbally.
- Check that the SLA credit does not turn into symbolic bonus days.
- Ask about power redundancy and the data center location relative to regional risks.
- Run your own availability monitoring alongside the provider's reports.
Common SLA Phrasing and What It Really Means
| Contract wording | What it means in practice |
|---|---|
| Credit paid as bonus days | The refund is free rental days, not cash — the real value is lower than the percentage suggests |
| SLA covers the data center's network infrastructure | It doesn't cover the link to your specific server inside the rack or equipment the client installed |
| Scheduled maintenance doesn't count as downtime | The data center can exclude pre-announced maintenance windows from the SLA calculation |
| Force majeure is excluded from the calculation | Natural disasters and external events outside the data center's control don't trigger a credit |
Data Center SLA vs Hosting Provider SLA
| Layer | What it covers | Where to escalate |
|---|---|---|
| Data center SLA | Power, cooling, the link to your rack | Usually only through the hosting provider |
| Hosting provider SLA | Server uptime and support | The provider's support team |
| Client-side monitoring | Early detection of a problem | Your own tools and alerts |
| Backups | Data recovery from any failure | The client's own backup policy |
When a Data Center SLA Doesn't Matter
- Downtime from an application-layer DDoS attack — that's covered by a separate defense, not the infrastructure SLA
- An administrator's mistake (a wrong command, deleted data) — that's the client's own responsibility
- The server runs without network or disk redundancy on the client's side, even though the data center redundant everything on its own
- The contract isn't signed directly with the data center but through a reseller who sets their own compensation terms for the end client
How SLA Credits Are Calculated
A typical compensation scheme pays a percentage of the monthly rental cost for each hour of downtime beyond the guaranteed level, capped at 100% of the monthly fee. In other words, even a multi-day outage usually won't net the client more than one month's rent — the credit covers the inconvenience, not the business's lost revenue. That gap matters when choosing between a cheap data center with no explicit SLA and a pricier one with a transparent credit scheme: the credit itself is rarely large, but having one at all signals the provider's level of accountability.
Frequently asked questions
If a data center is advertised as Tier III, does that mean the hosting provider's own SLA matches that level?
Not necessarily: the Tier level describes redundancy in the building's own engineering systems, while the SLA a client signs with a hosting provider can be softer or stricter, since it also covers the server itself, the network inside the rack, and support. The two documents are worth reading separately, not assuming a high Tier automatically carries into the provider contract.
If a data center SLA excludes scheduled maintenance from downtime calculations, is that a warning sign?
Excluding scheduled maintenance on its own is standard industry practice rather than a red flag, as long as maintenance windows are announced in advance and stay within reasonable bounds. The real concern appears when the wording is vague and never specifies how often or how long such work can run, since that vagueness lets any outage get written off afterward.
Is it worth paying extra for a Tier IV data center for a small project?
For a small project with a normal maintenance window and tolerance for the occasional brief outage, paying extra for the highest level of redundancy usually does not pay off. Tier IV earns its cost where every minute of downtime is expensive: billing, financial services, a client's critical infrastructure, workloads where power and network redundancy make a real difference.
Why look at the data center SLA at all if the client only signs a contract with the hosting provider?
The data center SLA sets a ceiling the provider can never physically exceed: if the building itself does not have redundant power and network, no promise in the provider's contract can fix that. So the data center SLA is worth treating as the foundation the provider's own contract is built on, not a document unrelated to the client.