How to Read Hosting SLAs and Terms

Most people sign up for hosting by comparing disk space, bandwidth and price, then scroll past the SLA and terms as fast as possible. Months later, a short outage or a resource limit kicks in, and that same fine print suddenly becomes very important. If you run an e‑commerce store, agency portfolio, SaaS app or even a busy blog, the way your hosting SLA (Service Level Agreement) and terms are written can directly affect your revenue, reputation and support workload.

In this article, we will walk through how to read hosting SLAs and terms like a technical decision-maker, not just a buyer checking out a cart. We will decode uptime percentages (99.5%, 99.9%, 99.99%), explain how refund policies and service credits actually work, and highlight the hidden limits that often sit behind words like “unlimited”. As the dchost.com team, we see both sides every day: real customer expectations and what the contract actually promises. The goal here is simple: after reading, you should be able to look at any hosting SLA and quickly decide whether it matches the risk level and uptime your project really needs.

Why Hosting SLAs Matter More Than Price Tags

A hosting SLA is not just legal decoration. It is a technical promise translated into contractual language. It defines:

• Availability: How often your service is expected to be reachable.
• Scope: Exactly what is being guaranteed (network, power, control panel, whole stack?).
• Compensation: What happens if the provider does not meet the target.
• Responsibilities: Which parts are your job (e.g. application bugs, configuration) and which belong to the provider.

If you are running a casual personal blog, a light SLA might be acceptable. For a store that processes payments 24/7, or an agency hosting dozens of client sites, the SLA becomes part of your own promise to your customers. A weak SLA can create an ugly chain reaction: a few minutes of downtime, confused support responses, no meaningful credits, and you stuck explaining “our provider says this was scheduled maintenance, so it does not count.”

We have a separate article dedicated to what 99.9% uptime really means and how to read uptime SLAs without guessing. Here we will go broader and include refund policies and the hidden limits that rarely appear on the pricing page.

Decoding Uptime Percentages: What 99.5%, 99.9% and 99.99% Really Mean

Uptime is usually the first big number you see in a hosting SLA: 99.5%, 99.9%, 99.95%, 99.99%… They all look high, but the real question is: how much downtime is actually allowed?

How Uptime Is Calculated

In most SLAs, uptime is calculated as:

Uptime % = (Total time - Downtime) / Total time × 100

“Total time” is usually one month. So if a month has 30 days:

• Total minutes in month = 30 × 24 × 60 = 43,200 minutes.

Here is what common uptime percentages allow as downtime per month and per year:

Notice how the difference between 99.9% and 99.99% is not “0.09%”; it is the difference between tolerating about 43 minutes vs about 4 minutes of outage in a month.

What Exactly Counts as Downtime?

This is the first place the SLA details really matter. Typical questions to check:

• What layer is guaranteed? Network only? Power only? Or the full hosting service including web server and database?
• How is downtime measured? From the provider's monitoring, from your monitoring, or both?
• Is degraded performance counted? For example, if the site responds in 30 seconds instead of 1 second, does this count as “up” or “down”?
• Is DNS included? If DNS is unavailable but servers are fine, does that count?

Some SLAs only measure core network connectivity inside the data center. Others commit to the full hosting stack, which is more meaningful for most website owners. At dchost.com we pay close attention to this distinction internally: network uptime is one metric, but what matters to you is whether your site actually answers visitors in a reasonable time.

If you want to go deeper into availability concepts in general, we also recommend our article on what uptime is and how to ensure continuous availability for websites.

Common Uptime Gotchas Hidden in SLAs

Even when a provider advertises 99.9% or 99.99%, there are often exclusions that significantly reduce what you actually get. Always look for these sections:

• Scheduled maintenance: Many SLAs exclude planned maintenance windows completely, even if they happen during your peak hours.
• Force majeure: Natural disasters, regional power grid issues, large-scale internet problems, etc., are typically excluded.
• Customer-caused incidents: Misconfiguration, insecure scripts, abusive traffic generated by your site, or exceeding resource limits usually do not count as SLA downtime.
• DDoS attacks: If the provider offers basic protection but a larger DDoS still affects your service, check whether this is covered or excluded.

We have a whole guide on DDoS protection strategies for small and medium websites; it is worth understanding how your own mitigation setup aligns with the SLA language around attacks.

Refunds vs Service Credits: How SLA Compensation Really Works

Many people assume that if an SLA is breached, they will “get their money back.” In reality, most hosting SLAs compensate you with service credits, not cash refunds, and often only if you follow a specific process.

Typical SLA Compensation Model

While every provider is different, a common pattern looks like this:

• Uptime is checked monthly (for example, 99.9% target).
• If actual uptime falls below that target, you become eligible for a credit.
• You must open a ticket within a certain time frame (e.g. 7–30 days) to request the credit.
• The credit is applied to a future invoice, not refunded to your payment card.
• Credits are capped (for example, maximum 50–100% of that month’s fee).

The exact percentages vary. You may see language like: “If monthly uptime is between 99.0% and 99.9%, customer is entitled to a 10% credit; between 95.0% and 99.0%, a 25% credit; below 95.0%, a 100% credit.” The key takeaway: you usually need to ask for it, and the amount is tied to the hosting fee only, not your lost revenue.

Questions to Ask About SLA Credits

When reviewing an SLA, it is useful to answer these questions explicitly:

• Is compensation automatic? Or must you file a claim ticket?
• What proof is required? Provider logs only, or do they accept your own monitoring data?
• What is the timeframe? How many days after the incident do you have to claim?
• What is the maximum credit? Can it exceed the monthly fee if the outage is severe?
• Does compensation apply to add-ons? For example, extra IPs, backups, or dedicated hardware?

At dchost.com we design SLAs to be understandable from the start: if there is an uptime guarantee, we also make clear what the process is for claiming credits and which services are covered. The aim is not to hide behind process, but to have a predictable, auditable way to handle rare incidents.

Example: Calculating a Credit from Downtime

Imagine a VPS plan costs 50 € per month and comes with a 99.9% uptime SLA. In one month, you experience 90 minutes of verified downtime that is counted under the SLA.

• Max allowed downtime at 99.9% ≈ 43 minutes.
• Actual downtime: 90 minutes.
• SLA shortfall: 90 − 43 = 47 minutes.

Now assume the SLA states:

• 99.0–99.9%: 10% credit
• 95.0–99.0%: 25% credit
• < 95.0%: 100% credit

90 minutes of downtime in a 30‑day month gives roughly 99.79% uptime, which falls into the 10% credit band. Your credit would be:

50 € × 10% = 5 €

Next month, 5 € is discounted from your bill. There is no extra compensation for lost sales or marketing spend. That is why for critical projects, you should pair SLA protection with your own uptime monitoring and a solid backup and disaster‑recovery plan.

For monitoring, our website uptime monitoring and alerting guide for small businesses is a practical place to start.

Hidden Limits in Hosting Terms You Should Always Check

Advertising space is limited; terms of service are not. Many important limits never appear on the pricing page but live deep inside the T&Cs or Acceptable Use Policy. Here are the main ones you should always look for.

1. “Unlimited” Disk Space and Bandwidth

“Unlimited” often really means “no fixed quota, but subject to fair use.” Common hidden details include:

• File count (inode) limits: Even if disk space is unlimited, the number of files and directories may be restricted.
• Type of content: Some providers forbid using shared hosting as pure backup storage, file sharing, or archival.
• Backup eligibility: Accounts above a certain size (for example, 50–100 GB) may be excluded from automatic backups.
• Bandwidth shaping: After a certain traffic level, your connection might be throttled or require an upgrade.

We have written an entire piece on how to avoid inode limits on shared hosting. Reading that together with your provider's “unlimited” claims will give you a much clearer picture of what you can actually store.

2. CPU, RAM and I/O Throttling on Shared Hosting

Even on “unlimited” shared hosting, each account typically has:

• A maximum number of CPU cores or percentage of CPU time.
• Limits on RAM usage per process or per account.
• I/O limits (how fast you can read/write to disk).
• Entry process or concurrent connection limits.

These limits protect other customers from “noisy neighbours”, but they also mean that a sudden spike in your site traffic can hit a wall even if your disk and bandwidth are far from “full”. When you see errors like “Resource limit reached” or random 503s under load, you are often running into these caps.

To understand these mechanisms better, have a look at our article on cPanel resource limits and fixing the “Resource Limit Reached” error. It explains how CPU, I/O and concurrent process limits are enforced in real shared hosting environments.

3. Email Sending Limits and Spam Policies

Email is another classic area where limits live in the fine print:

• Maximum emails per hour or per day per account.
• Restrictions on bulk or marketing email from shared hosting.
• Requirements to use authenticated SMTP, SPF, DKIM and DMARC.
• Automatic blocking or suspension if your messages trigger spam complaints or blocklists.

If your business relies heavily on transactional or marketing email, you should know exactly how many messages per hour you can send and what the escalation path is if something gets flagged as spam. Combine this with solid DNS configuration and reputation management. Our guide on why emails go to spam and how to improve deliverability on shared hosting and VPS is a good starting checklist.

4. Backup and Retention Policies

Almost every hosting landing page mentions “free backups,” but the details vary hugely and are always defined in the terms:

• Frequency: Daily, weekly, hourly? Full or incremental?
• Retention: How many restore points are kept? 7 days, 30 days, more?
• Scope: Files only, or databases and email as well?
• Location: Same server, same data center, or geographically separate?
• Guarantees: Are backups “best effort” or covered by an SLA?

Many providers explicitly say backups are not guaranteed and are for convenience only. That means your real recovery guarantee depends on your own backup strategy, not just what comes bundled with the hosting plan.

We strongly recommend reading our explanation of the 3‑2‑1 backup strategy and how to automate backups on cPanel, Plesk and VPS. It will help you design a backup plan that does not fall apart when you actually need a restore.

5. Support Scope, Response Times and Managed vs Unmanaged

The SLA and ToS also define what the support team is responsible for and how fast they aim to respond:

• Is your plan managed (provider maintains OS, patches, services) or unmanaged (you manage everything above the hypervisor)?
• Are application-level issues (for example, WordPress plug‑ins, custom code) supported or best‑effort only?
• Are there target response times for critical tickets, or only general “we aim to respond quickly” statements?
• Is 24/7 support truly 24/7 with engineers, or only ticket reception outside office hours?

For teams moving from shared hosting to VPS, these questions are crucial. Our article on managed vs unmanaged VPS hosting, responsibilities and hidden costs goes through real‑world examples of where the provider’s job ends and yours begins.

6. IP Addresses, IPv4 Scarcity and Extra Charges

Public IPv4 addresses have become significantly more expensive in recent years, and this often shows up in hosting terms before it shows on the main pricing page:

• Extra monthly fees per dedicated IPv4 address.
• Limits on how many IPs you can attach to one server or account.
• Justification policies (for example, requiring a technical reason for multiple IPs).
• Rules for IP reputation, blacklisting and abuse complaints.

If your stack uses many IPs (SSL on older stacks, separate IPs for email, staging, etc.), factor these policies into your long‑term budget. For deeper context, we have written extensively about why IPv4 address prices are hitting record highs and what you can do about it. Understanding that bigger picture makes the IP section of the ToS much easier to read.

Maintenance Windows, Force Majeure and Other Fine Print

Two sections are often skipped but have a big impact on real‑world uptime: maintenance windows and force majeure.

Scheduled Maintenance

Most hosting providers reserve the right to perform maintenance on the underlying infrastructure. Key things to check:

• Notification period: Do they promise to warn you in advance (for example, 3–7 days)?
• Time windows: Is maintenance concentrated in off‑peak hours for your region, or only for the data center time zone?
• Inclusion in uptime: Is scheduled maintenance excluded from uptime calculations?
• Expected impact: Do they commit to keeping maintenance windows short and minimizing downtime?

For example, an SLA may say that up to 2 hours per month of scheduled maintenance is not counted as downtime. If that maintenance always falls right in the middle of your own traffic peak, the effective availability for your business is lower than the advertised SLA number suggests.

Force Majeure and External Dependencies

Force majeure clauses list events that are beyond the provider’s reasonable control. Typical examples:

• Natural disasters (earthquakes, floods, fires).
• Widespread power grid failures.
• Large‑scale routing issues on the global internet.
• Regional government‑mandated shutdowns.

These clauses are standard in contracts, but you still want to understand how they might apply. For multi‑region or multi‑provider architectures, you can mitigate many of these risks on your side with redundancy and failover planning, even if they are not covered by SLA credits.

That is where an explicit disaster‑recovery (DR) plan comes in. If you are designing or updating yours, our practical guide on how to write a no‑drama DR plan with clear RPO/RTO and real restore drills will help you connect the dots between SLAs and your own responsibilities.

How We Approach SLAs and Terms at dchost.com

From the dchost.com side, we see SLAs as part of the product, not just legal text. For our shared hosting, VPS, dedicated servers and colocation services, we design SLA and terms with a few guiding principles:

• Clarity over marketing: If we publish an uptime target, we also define what layer it applies to and how downtime is measured.
• Realistic guarantees: We would rather commit to a strong SLA we can consistently meet than promise unrealistic “100% uptime” that quietly excludes half of real incidents.
• Transparent responsibilities: Especially for VPS, dedicated and colocation, we make it clear which parts of the stack we manage and which you control.
• Actionable processes: For credits, escalations or restore requests, we aim to have processes that are simple, documented and testable.

On the operational side, our teams use monitoring, capacity planning, redundancy and backup strategies very similar to what we explain publicly on the blog. The same patterns behind our articles on uptime, monitoring, backups, IPv4 strategy and DR planning are reflected in how we run our own infrastructure for customers.

When you evaluate any provider (including us), do not hesitate to ask support specific SLA questions: how they measure incidents, how often credits are actually granted, and what internal playbooks look like when there is a large outage. Good answers here are often a stronger reliability signal than the raw uptime number on the front page.

Practical Checklist: Reviewing a Hosting SLA Before You Commit

To make this concrete, here is a quick checklist you can use the next time you are about to sign up for a hosting plan or move infrastructure.

1. Uptime target and scope
   • What percentage is promised (99.5%, 99.9%, 99.99%)?
   • Does it cover network only, or the full hosting service?
   • Is DNS part of the uptime calculation?
2. Downtime definition
   • What exactly counts as downtime (complete outage, errors above a threshold, extreme latency)?
   • Are partial outages counted (some customers affected, some not)?
   • Is scheduled maintenance excluded, and if so, under what conditions?
3. Measurement and evidence
   • Whose monitoring is authoritative—the provider’s, yours, or both?
   • Can you submit your own logs or status pages as evidence?
4. Compensation model
   • Are there clear bands (for example, 99.0–99.9% → 10% credit)?
   • Is compensation automatic or do you need to open a ticket?
   • What is the maximum monthly credit?
5. Resource limits
   • What are the CPU, RAM, I/O, inode and bandwidth limits for your plan?
   • Are there specific thresholds that trigger throttling or suspension?
   • Are “unlimited” resources subject to fair use wording?
6. Email and IP policies
   • What are the hourly/daily email send limits?
   • What are the rules around bulk email and spam complaints?
   • How many IPv4 addresses are included, and what are the extra costs?
7. Backup and restore
   • How often are backups taken and how long are they kept?
   • What is the process and typical time to restore a backup?
   • Are backups themselves part of any SLA?
8. Support scope and response
   • Is the service managed or unmanaged?
   • What are the target response times for critical tickets?
   • Are application issues covered or best‑effort only?
9. Maintenance and force majeure
   • How much scheduled maintenance per month is expected?
   • How far in advance are you notified?
   • What events are excluded as force majeure?
10. Exit and migration
    • How easy is it to get a full backup of your data if you leave?
    • Are there any fees or conditions related to migration or termination?

Wrapping Up: Turn SLAs from Legalese into a Tool You Actually Use

Hosting SLAs and terms do not have to be mysterious or intimidating. Once you know where to look—uptime definitions, exclusions, compensation rules, hidden resource limits and backup policies—they become a practical tool to align expectations between you and your provider. Instead of discovering limits during a crisis, you can decide up front which trade‑offs are acceptable and where you need stronger guarantees or additional redundancy.

As the dchost.com team, our recommendation is to treat the SLA as an integral part of your infrastructure design. Pair it with your own monitoring, backup and disaster‑recovery strategy, and you will be in a far better position when something unexpected happens. If you are planning a new project or considering a migration, feel free to compare our published SLAs and blog resources—for example, our guides on uptime, monitoring, backups and IPv4 planning—to your current setup. And if you are unsure how a particular clause translates to real‑world risk for your website or application, reach out to our support team; we are happy to walk through it with you in plain language.