Uptime Guarantees and SLAs: Reading the Fine Print

“99.9% uptime.”

It is one of the most common promises you'll see when comparing web hosting providers.

But what does 99.9% uptime actually mean?

For many website owners, the number sounds almost perfect. After all, 99.9% is very close to 100%.

The problem is that a percentage by itself doesn't tell you how much downtime you're actually accepting, how the provider calculates that downtime, what the guarantee excludes, or what happens when the provider misses its target.

If you're choosing hosting for an online shop, business website, SaaS application, booking system, or any service that needs to remain accessible around the clock, these details matter.

A hosting provider's uptime figure should therefore be treated as the beginning of your investigation, not the end.

This guide explains what 99.9% uptime means in actual minutes and hours, how hosting SLAs work, what exclusions to look for, how to independently monitor your website, and what questions to ask before signing a long-term hosting contract.

What Does 99.9% Uptime Mean?

Uptime is the percentage of time that a server, service, or website is available during a defined measurement period.

A simple calculation is:

Uptime % = (Total time − Downtime) ÷ Total time × 100

That means 99.9% uptime does not mean your website can never go offline.

It means that over the measurement period, the provider is targeting availability of 99.9% of the applicable time.

The remaining 0.1% represents potential downtime.

And when you convert that percentage into actual time, the number becomes much easier to understand.

How Much Downtime Is 99.9%?

Consider a 30-day month.

There are:

30 × 24 × 60 = 43,200 minutes

At 99.9% uptime, 0.1% represents:

43,200 × 0.001 = 43.2 minutes

So:

Uptime

Approximate downtime in 30 days

99%

7 hours 12 minutes

99.5%

3 hours 36 minutes

99.9%

43 minutes

99.95%

22 minutes

99.99%

4 minutes 19 seconds

99.999%

26 seconds

These figures are useful because they put hosting uptime claims into practical terms.

A difference of only a few decimal places can represent a substantial difference in allowed downtime.

Why 99.9% Isn't the Same for Every Business

Forty-three minutes of downtime may sound insignificant.

But its impact depends heavily on when the downtime happens.

Imagine two businesses.

Business A: Corporate Website

A company website mainly provides information about the organization.

If the website is unavailable for 20 minutes at 3:00 a.m., the immediate commercial impact may be relatively small.

Business B: Online Store

An e-commerce website receives most of its orders between 8:00 p.m. and 11:00 p.m.

A 40-minute outage during that period could prevent customers from browsing products, checking out, or completing payments.

The same uptime percentage therefore does not necessarily represent the same business risk.

Uptime should always be evaluated together with the value of the service being hosted and the times when customers depend on it most.

99.9% Uptime Is a Budget, Not a Promise of Perfection

One of the most useful ways to understand uptime is to think of it as a downtime budget.

At 99.9% uptime, you have roughly:

43 minutes of downtime per 30-day month.

That doesn't mean the provider is promising to deliberately allow 43 minutes of downtime.

It means that the mathematical difference between 100% and 99.9% is approximately 43 minutes during that period.

This distinction is important when evaluating SLAs.

A provider advertising 99.9% uptime isn't necessarily claiming that your website will experience 43 minutes of downtime every month.

Rather, the SLA defines an availability target and the circumstances under which downtime counts toward that target.

What Is a Hosting SLA?

An SLA, or Service Level Agreement, defines the service commitments between a provider and its customer.

For hosting, an SLA may specify:

• The availability target

• How availability is measured

• What counts as downtime

• What downtime is excluded

• How scheduled maintenance is treated

• How incidents are calculated

• Whether customers receive service credits

• How credits are requested

• How quickly claims must be submitted

• Which services are covered

This is why simply comparing:

Provider A — 99.9%

with:

Provider B — 99.95%

may not tell you which agreement provides more meaningful protection.

You need to read the actual SLA.

What Does a Hosting Uptime Guarantee Usually Exclude?

This is where many customers discover that the headline number is more complicated than expected.

Hosting SLAs commonly define circumstances that are excluded from availability calculations.

Potential exclusions can include:

Scheduled Maintenance

A provider may perform planned maintenance to upgrade infrastructure, replace hardware, apply security patches, or improve the network.

The SLA may exclude properly scheduled maintenance from downtime calculations.

That isn't necessarily a problem.

The important questions are:

• Is maintenance announced in advance?

• How much notice is provided?

• Are maintenance windows defined?

• Does maintenance happen during low-traffic periods?

• Is emergency maintenance treated differently?

A well-defined maintenance policy is easier to understand than an SLA that simply says “maintenance is excluded.”

Customer-Side Problems

Your hosting provider cannot necessarily be responsible for every reason your website becomes unavailable.

For example, downtime could result from:

• A broken application update

• Incorrect DNS configuration

• Expired domain registration

• Invalid SSL configuration

• A faulty plugin

• An application crash

• Incorrect firewall rules

• Resource exhaustion caused by the customer's software

The SLA should make clear which situations are considered provider downtime and which are outside the provider's responsibility.

Third-Party Network Problems

Your hosting provider may operate the server successfully while a problem occurs elsewhere in the internet infrastructure.

For example:

Your website → hosting network → upstream network → ISP → customer

A disruption at an ISP or external network does not necessarily mean the hosting server itself is down.

This is one reason independent monitoring from different networks is valuable.

Force Majeure

SLAs may also exclude events outside reasonable control, such as certain natural disasters, major infrastructure failures, or other extraordinary circumstances.

Again, the important thing is not simply whether exclusions exist.

It's what they cover and how clearly they are defined.

How Is Uptime Actually Measured?

This is one of the most important questions to ask a hosting provider.

There is a difference between:

“Our server responded to our monitoring probe.”

and:

“A customer successfully loaded the website.”

Those aren't necessarily the same thing.

A server can respond to a basic availability check while an application is broken.

For example:

Server: ONLINE

HTTP service: RESPONDING

Database: ERROR

Application: ERROR

Homepage: NOT LOADING

A basic server check may consider the machine available even though customers cannot use the website properly.

Server Uptime vs Website Availability

Consider an online store.

A monitoring system checks:

https://example.com

and receives an HTTP response.

It reports:

UP

But the checkout application is returning errors.

Customers can visit the homepage but cannot complete purchases.

From the server's perspective, the infrastructure may be operational.

From the customer's perspective, the service is partially unavailable.

This is why website owners should consider monitoring more than just whether a server responds.

Depending on the application, useful checks may include:

• Homepage availability

• Login

• Checkout

• API endpoints

• Database-dependent pages

• Payment workflows

• SSL certificate validity

• DNS resolution

• Response time

Why Independent Monitoring Matters

Provider monitoring is useful because the hosting company has direct visibility into its infrastructure.

But customers should also consider independent monitoring.

Why?

Because your customers don't access your website from the provider's internal monitoring network.

They access it through:

• Safaricom

• Airtel

• Fibre providers

• Corporate networks

• Wi-Fi

• Mobile networks

• International networks

The experience can therefore differ depending on where the visitor is located.

For a Kenyan business, monitoring from or near Kenya can provide additional context about local accessibility.

A website might be functioning perfectly from a monitoring location in Europe while customers in Kenya are experiencing connectivity problems.

Independent monitoring gives you another perspective.

How to Monitor Your Website Yourself

You don't need an expensive enterprise monitoring system to start monitoring your website.

Basic monitoring tools can periodically request your website and notify you when it becomes unavailable.

A simple monitoring setup might look like this:

Monitoring Service

       ↓

Checks website

       ↓

Website responds?

   ↙           ↘

 YES           NO

  ↓             ↓

Record UP    Send Alert

                ↓

          Phone / Email

Configure monitoring to check your website at regular intervals.

Depending on your business requirements, you may monitor every few minutes.

The monitoring system should record:

• Time of failure

• Time of recovery

• Duration

• HTTP status

• Response time

• Monitoring location

Over time, these records give you your own availability history.

For practical monitoring guidance, see the SteboHost .

Why a One-Minute Alert Can Matter

Imagine your website goes offline at 10:03 p.m.

Without monitoring, you might discover it at:

10:45 p.m.

That's 42 minutes before anyone notices.

With monitoring:

10:03 p.m. — Website fails

10:04 p.m. — Alert received

10:06 p.m. — Investigation begins

10:12 p.m. — Service restored

The outage may still have happened, but the incident becomes much smaller.

Monitoring doesn't prevent infrastructure failures.

It reduces the amount of time your business can remain unaware of them.

Don't Monitor Only the Homepage

A homepage check is useful, but it isn't enough for many businesses.

Imagine your website is online but the checkout page is broken.

A basic uptime monitor might report:

Website: UP

Your customers might report:

I can't place an order.

For an e-commerce website, consider monitoring important customer journeys.

For example:

Basic website

• Homepage

• Contact page

• SSL certificate

Business website

• Homepage

• Contact form

• Important landing pages

• SSL

• DNS

E-commerce website

• Homepage

• Product page

• Cart

• Checkout

• Payment flow

SaaS application

• Login

• Dashboard

• API

• Key application endpoint

The more important the application, the more useful service-level monitoring becomes.

What Happens When a Provider Misses Its SLA?

This is another question customers often overlook.

Suppose a provider guarantees a particular availability level and fails to meet it.

What happens next?

Some SLAs provide service credits.

For example, an SLA might state that customers are entitled to a percentage credit depending on the measured availability.

But the exact terms vary by provider.

Look for answers to questions such as:

• Is compensation automatic?

• Does the customer need to submit a claim?

• How long does the customer have to submit it?

• What evidence is required?

• Is there a maximum credit?

• Does the credit apply to all hosting plans?

• Are certain services excluded?

The procedure matters almost as much as the credit itself.

If a customer must independently discover the outage, document it, calculate the downtime, submit evidence, and file a claim within a short period, many customers may never claim the credit.

Service Credits Are Not the Same as Reliability

This is an important distinction.

Suppose two providers experience an outage.

Provider A gives customers a service credit.

Provider B also gives customers a service credit.

That doesn't tell you how frequently either provider experiences incidents.

A refund doesn't restore:

• Lost sales

• Missed leads

• Failed transactions

• Customer trust

• Missed appointments

• Delayed communications

• Abandoned shopping carts

The most valuable question is therefore not simply:

“How much money do I get if you miss your SLA?”

It's:

“How reliable has this service actually been?”

Ask for Incident History

Before committing to an annual hosting contract, ask whether the provider maintains an incident history or public status page.

A useful status page may show:

• Current service status

• Past incidents

• Incident dates

• Affected services

• Resolution status

• Maintenance events

Historical information gives customers something that a marketing claim cannot:

evidence.

If a provider publishes its incident history openly, you can examine how the infrastructure has actually performed rather than relying exclusively on a headline percentage.

Questions to Ask Your Hosting Provider

Before purchasing hosting, ask:

1. What does your uptime percentage measure?

Is it:

• Server availability?

• Network availability?

• HTTP availability?

• Application availability?

2. How is downtime calculated?

Ask whether measurements are taken continuously and from which monitoring locations.

3. What exclusions apply?

Request the actual SLA rather than relying on the sales page.

4. How is scheduled maintenance handled?

Find out how much notice you receive and whether maintenance is excluded.

5. What happens if the SLA is missed?

Ask about service credits and the claims process.

6. Do you publish incident history?

A public status page can provide useful transparency.

7. Can customers use independent monitoring?

A provider should not object to customers independently monitoring their own websites.

99.9% vs 99.99%: Should You Always Choose the Higher Number?

Not necessarily.

The higher percentage may indicate a tighter availability target, but uptime should be considered alongside:

• SLA definitions

• Measurement methodology

• Exclusions

• Infrastructure

• Support response

• Backup systems

• Monitoring

• Incident history

• Recovery procedures

• Your application's requirements

A hosting plan with a higher advertised uptime percentage isn't automatically the right choice for every website.

The useful comparison is the whole reliability model, not one number.

What Businesses Should Do About Uptime

If your website generates revenue or handles important customer activity, create your own basic availability strategy.

1. Choose a provider with a clearly defined SLA

Don't rely exclusively on an uptime percentage displayed on a pricing page.

2. Read the exclusions

Understand exactly what counts as downtime.

3. Monitor independently

Use an external monitoring service to record your website's availability.

4. Monitor from relevant locations

If most of your customers are in Kenya, include monitoring that gives you visibility into Kenyan connectivity.

5. Monitor critical functions

Don't stop at the homepage if your business depends on logins, checkout, APIs, or forms.

6. Set alerts

Make sure failures reach someone who can investigate them.

7. Keep backups

Uptime and backups solve different problems.

Monitoring tells you that something is wrong.

Backups help you recover from certain data or application failures.

8. Keep your own incident records

Record:

• Start time

• End time

• Duration

• Symptoms

• Cause

• Resolution

• Provider response

Over time, you'll have an independent reliability history.

Uptime Is Only One Part of Hosting Reliability

A reliable hosting environment involves more than keeping a server powered on.

Consider the entire chain:

Infrastructure

      ↓

Network

      ↓

DNS

      ↓

Web Server

      ↓

Database

      ↓

Application

      ↓

Website

      ↓

Customer

A problem at any stage can affect the customer's experience.

That's why businesses should evaluate hosting based on a combination of:

• Availability

• Performance

• Security

• Backups

• Monitoring

• Support

• Infrastructure

• Recovery procedures

• SLA transparency

Uptime is an important metric, but it is not the entire reliability story.

How SteboHost Approaches Uptime

At SteboHost, uptime should be viewed as something customers can measure and verify, not simply a number they are expected to trust.

A public status page provides visibility into service incidents and maintenance, while independent monitoring allows customers to measure their own websites from outside the hosting infrastructure.

Customers can also set up their own uptime checks and alerts so that they know when their website becomes unavailable.

This creates two useful perspectives:

Provider monitoring: What is happening within the hosting infrastructure?

Independent monitoring: What are visitors actually experiencing?

For businesses that depend heavily on their websites, having both perspectives provides better visibility than relying on a single uptime number.

Explore SteboHost .

A Simple Uptime Verification Checklist

Before signing your next hosting contract, check the following:

• Calculate the actual downtime represented by the advertised uptime.

• Read the provider's SLA.

• Identify all downtime exclusions.

• Check how uptime is measured.

• Find out where monitoring probes are located.

• Check whether application failures count as downtime.

• Review scheduled maintenance policies.

• Check the provider's incident history.

• Find the public status page.

• Set up independent website monitoring.

• Configure phone or email alerts.

• Monitor important application functions.

• Understand the SLA credit process.

• Maintain your own uptime records.

Frequently Asked Questions

Is 99.9% uptime good?

99.9% uptime represents approximately 43 minutes of downtime in a 30-day month. Whether that level is appropriate depends on the website, application, business hours, and consequences of downtime.

How many hours of downtime is 99.9% uptime?

Over a 30-day month, 99.9% uptime corresponds to approximately 43 minutes and 12 seconds of downtime.

Over a 365-day year, it corresponds to approximately 8 hours and 46 minutes.

Is 99.99% uptime better than 99.9%?

99.99% represents a smaller downtime allowance than 99.9%. However, customers should compare the actual SLA definitions, exclusions, monitoring methodology, infrastructure, and incident history rather than comparing percentages alone.

Does 99.9% uptime mean my website will never go down?

No. It represents an availability target or guarantee under the terms defined by the provider's SLA. Short outages can still occur.

What is an SLA in web hosting?

An SLA, or Service Level Agreement, defines the provider's service commitments, including availability targets, measurement methods, exclusions, and potential remedies when commitments are not met.

How can I check my website's uptime?

Use an independent uptime-monitoring service that periodically checks your website and records availability. Configure alerts so that you're notified when the site becomes unavailable.

Can my website be down even when the server is online?

Yes. Your application, database, DNS, SSL configuration, or other components can fail while the underlying server remains operational.

Does scheduled maintenance count as downtime?

It depends on the provider's SLA. Many hosting SLAs exclude properly scheduled maintenance, which is why you should read the specific agreement rather than assume all downtime is counted.

Should I monitor my website if my hosting provider already does?

Yes. Independent monitoring gives you a separate view of availability and can help identify problems that may not appear in infrastructure-level monitoring.

Conclusion

99.9% uptime sounds impressive until you convert it into minutes.

In a 30-day month, 99.9% allows approximately 43 minutes of downtime under the applicable measurement rules.

That number alone, however, doesn't tell you how reliable a hosting service really is.

To evaluate uptime properly, look beyond the percentage.

Read the SLA. Understand the exclusions. Find out how uptime is measured. Examine incident history. Check whether the provider publishes a status page. Then independently monitor your own website.

For businesses in Kenya, independent monitoring can provide an additional perspective on what customers are actually experiencing across local networks.

The most useful hosting question isn't simply:

“Do you guarantee 99.9% uptime?”

It's:

“Show me how you measure it, what you exclude, what happened over the last 12 months, and what happens when the target is missed.”

That's how you turn an uptime percentage from a marketing number into something you can actually evaluate.