Your site worked at breakfast. By lunch, a customer emails to say checkout shows a blank page. You have no idea how long it has been broken. That gap between “it broke” and “we noticed” is exactly what this guide covers. So, what is uptime? Uptime is the percentage of time your website or server stays online and usable for visitors.
The number looks simple. However, it hides a lot. For example, a 99.9% promise still allows almost nine hours of downtime a year. If you want the prevention side first, our guide on tips to prevent downtime pairs well with this one.
In this guide, you will learn what uptime means, how to calculate it and what each “nine” allows. You will also see why downtime hurts revenue and SEO, then set up website availability monitoring step by step.
TL;DR: Uptime in 60 Seconds
Short on time? Here is the whole guide in a few lines:
- Uptime is the share of time a site or server is up. The formula is uptime minutes divided by total minutes, times 100.
- 99.9% uptime still allows about 43 minutes of downtime a month. In contrast, 99.99% allows about 4 minutes.
- Downtime is expensive. In ITIC’s 2024 survey, over 90% of mid-size and large firms said one hour of downtime costs more than $300,000.
- Google notices. Pages that return server errors for several days can drop out of the index.
- Monitor from outside your server, from at least two locations, with alerts that reach a human fast.
- 100% uptime is not realistic. Instead, set a target, track it monthly and shrink your time to recover.
What Is Uptime?
Uptime is the amount of time a website, server or service is running and reachable, usually shown as a percentage of a given period. The opposite is downtime: any time visitors cannot load the site or use it.
Think of uptime like a shop’s opening hours. If the sign says “open 24/7” but the door is locked for an hour every night, customers notice. In the same way, your site’s uptime figure tells visitors (and Google) how often the door actually opens.
A few things worth knowing:
- Uptime is always measured over a period, such as a day, a month or a year. Monthly is the most common because hosting SLAs bill monthly.
- A server can be “up” while the website on it is broken. For instance, a database crash can leave Nginx running but every page showing an error.
- Planned maintenance is still downtime for visitors, even if your host’s SLA excludes it.
- Monitoring tools measure uptime by sampling. As a result, your measured number depends on how often the tool checks.
Uptime vs. Availability vs. Reliability
People often use these three terms as if they mean the same thing. However, they answer different questions:
| Term | The question it answers | How it is measured |
|---|---|---|
| Uptime | Was the system running? | Time up ÷ total time |
| Availability | Could users actually complete what they came to do? | Successful checks ÷ total checks (or MTBF ÷ (MTBF + MTTR)) |
| Reliability | How rarely does it fail? | Mean time between failures (MTBF) |
Here is the part that trips people up. Your server can show 100% uptime while your checkout fails for every visitor. That situation is an availability problem. Only a monitor that tests the real user path will catch it.
What Is Uptime on a Server, Phone or Computer?
Outside of websites, uptime simply means how long a device has run since its last restart. On Linux, run the uptime command to see it. On Windows, open Task Manager and check the Performance tab. You can also run systeminfo and look for the boot time.
That said, a very long server uptime is not always good news. Months without a reboot can mean nobody applied kernel and security updates.
How to Calculate Uptime (With a Worked Example)
The uptime formula is short:
Uptime % = (Total time − Downtime) ÷ Total time × 100
Let’s say your monitor checks your site every 5 minutes. In a 30-day month (43,200 minutes), 9 checks fail in total. That equals roughly 45 minutes of downtime:
(43,200 − 45) ÷ 43,200 × 100 = 99.896%
So the site missed a 99.9% target, even though 45 minutes feels small.
There is a catch worth knowing. A 5-minute check interval can completely miss a 3-minute outage. Likewise, it can count a 6-minute outage as 5 or 10 minutes. For that reason, shorter intervals give a more accurate uptime figure.
MTBF, MTTR and Availability
Two more metrics explain why your number looks the way it does:
- MTBF (mean time between failures): the average time your site runs before it breaks.
- MTTR (mean time to recovery): the average time it takes to bring it back.
Availability = MTBF ÷ (MTBF + MTTR). Say your site fails once a month (MTBF of 720 hours) and each fix takes 1 hour. In that case, availability is 720 ÷ 721 = 99.86%. Cut the fix time to 15 minutes and availability jumps to about 99.97%. In other words, faster recovery often moves the number more than fewer failures.
The Nines: How Much Downtime Each Uptime Percentage Allows
Hosts love to quote “nines”. This table shows what each level actually allows, based on a 365.25-day year and a 30.44-day average month:
| Uptime | Per day | Per week | Per month | Per year |
|---|---|---|---|---|
| 99% (two nines) | 14m 24s | 1h 40m 48s | 7h 18m 20s | 3d 15h 39m |
| 99.5% | 7m 12s | 50m 24s | 3h 39m 10s | 1d 19h 49m |
| 99.9% (three nines) | 1m 26s | 10m 5s | 43m 50s | 8h 45m 58s |
| 99.95% | 43s | 5m 2s | 21m 55s | 4h 22m 59s |
| 99.99% (four nines) | 9s | 1m | 4m 23s | 52m 36s |
| 99.999% (five nines) | under 1s | 6s | 26s | 5m 16s |
If you only remember one line: every extra nine cuts allowed downtime by 10 times. It also usually costs far more than 10 times as much to achieve.
Is 99.9% Uptime Good?
For most business websites, yes. 99.9% is the standard baseline for hosting. It allows about 43 minutes of downtime a month. On the other hand, an online store doing serious volume should aim for 99.95% or better. For comparison, AWS commits to 99.99% monthly uptime for EC2 at the region level when you run instances across two or more Availability Zones.
Why 100% Uptime Is Not Realistic
Every site depends on things you do not control: DNS, your CDN, your cloud provider and the visitor’s own network. On top of that, deploys, updates and hardware failures all take time. That is why site reliability teams use an error budget. If your target is 99.9%, you “own” about 43 minutes a month to spend on risky changes. When the budget runs out, you pause releases and fix stability instead.
What Causes Website Downtime?
Most outages trace back to a short list of causes. Here they are, roughly from most to least common for small and mid-size sites.
1. Server Overload and Traffic Spikes
A sale, a viral post or a bot swarm can push CPU or RAM to 100%. Once that happens, PHP workers queue up and requests time out. Our guide on managing traffic spikes on a shared server shows how to plan for it.
2. Bad Deploys, Updates and Human Error
A plugin update, a broken config or a typo in a server block can take a site down in seconds. According to Uptime Institute’s 2025 outage analysis, nearly 40% of organizations had a major outage caused by human error in the past three years. Of those, 85% came from staff not following procedures or from flawed procedures.
3. Application and Database Errors
Code errors, exhausted database connections or a full disk usually surface as a 500 Internal Server Error. The server is technically up. The site, however, is not.
4. Third-Party and Upstream Failures
Your site relies on DNS providers, CDNs, payment gateways and cloud platforms. In fact, Uptime Institute’s 2026 report notes that about two-thirds of publicly reported outages over nine years came from third-party providers such as cloud, internet and telecom companies.
5. Expired SSL Certificates and Domains
An expired certificate makes browsers show a full-page security warning. Similarly, an expired domain makes the whole site vanish. Both are entirely preventable with monitoring and auto-renewal, such as a free Let’s Encrypt SSL certificate that renews itself.
6. DDoS Attacks and Malicious Bots
Attack traffic can exhaust bandwidth or server resources until real visitors cannot connect. Our guide on how to prevent DDoS attacks covers the layers that help.
7. Power and Hardware Failures
At the data-center level, Uptime Institute still lists power as the leading cause of impactful outages. Most often, UPS units, transfer switches and generators fail. You cannot fix this yourself. That is a big reason to choose a host carefully.
Why Uptime Matters: Revenue, SEO and Trust
Downtime Costs More Than Most Teams Expect
The numbers below come from large surveys. So treat them as a direction rather than a bill for your site:
| Source | Finding |
|---|---|
| ITIC 2024 Hourly Cost of Downtime survey | Over 90% of mid-size and large enterprises say 1 hour of downtime costs more than $300,000. Also, 41% put it at $1 million to over $5 million. |
| Uptime Institute Annual Outage Analysis 2026 | 57% of operators said their most recent major outage cost over $100,000. About 1 in 5 said it cost over $1 million. |
| New Relic 2025 Observability Forecast | High-impact IT outages have a median cost of $2 million per hour, which is roughly $33,000 per minute. |
| Oxford Economics and Splunk, 2024 | Downtime costs Global 2000 companies about $400 billion a year, around $200 million per company. |
For years, people quoted a Gartner figure of $5,600 per minute. That number dates back to 2014. Newer surveys therefore give a more accurate picture today.
For a small business, the math is simpler. Divide your monthly online revenue by 43,200 minutes. The result is your cost per minute of downtime, before you even count lost trust.
Downtime and SEO: What Google Actually Does
Short outages rarely hurt rankings. Long or repeated ones do. Google’s documentation on HTTP and network errors explains that 5xx errors make Googlebot slow down crawling. Pages that keep returning server errors are eventually dropped from the index.
Here is what Google recommends instead:
- Return a 503 status during planned or emergency downtime, ideally with a Retry-After header. Google’s guide to pausing a site temporarily recommends a 503 for short pauses.
- Keep it short. Google advises against serving 500, 503 or 429 codes for more than one or two days. URLs that return them over multiple days may drop out of the index. Its crawl rate guidance spells this out.
- Never use 403, 404 or 410 for temporary downtime. Those codes tell Google to remove the URLs.
Google repeated this advice recently. On October 21, 2026, Google Search Central reminded site owners to serve 503s during server downtime rather than letting requests time out.
Slow pages create a quieter form of downtime too. Back in 2016, Google found that visitors abandon 53% of mobile visits when a page takes longer than 3 seconds to load.
Trust, SLAs and Customer Expectations
Customers rarely tell you your site is down. Instead, they leave. For SaaS products and agencies, uptime also becomes a contract. If you promise clients 99.9% and miss it, you owe credits. You also lose credibility at renewal time.
Real-World Examples: When the Giants Went Down
Even the biggest platforms fail. Three recent incidents show how varied the causes are:
- AWS, October 19 to 20, 2025: A race condition in DynamoDB’s automated DNS management left a regional endpoint with an empty DNS record. The disruption in us-east-1 lasted about 14.5 hours, according to the AWS post-event summary.
- Cloudflare, November 18, 2025: A database permissions change doubled the size of a bot management file. As a result, proxies crashed and returned 5xx errors for about 5 hours and 46 minutes, as Cloudflare explained in its outage post-mortem.
- CrowdStrike, July 19, 2024: A faulty security update crashed an estimated 8.5 million Windows devices, according to Microsoft.
The lesson? You cannot prevent every outage. However, you can find out in minutes instead of hours. You can also make sure your team knows exactly what to do next.
How to Monitor Website Availability: Step by Step
Uptime monitoring means an outside service checks your site on a schedule and alerts you when a check fails. Here is how to set it up properly.
Step 1: Decide What “Up” Means for Your Site
Start by listing the pages and endpoints that make you money or keep users working. Usually that means the homepage, login, checkout, your API and any key landing pages. Monitoring only the homepage misses most real failures.
Step 2: Choose the Right Monitor Types
Each monitor type catches a different kind of failure. Most sites need at least the first five:
| Monitor type | What it checks | What it catches |
|---|---|---|
| HTTP(S) | Requests a URL and expects a 2xx or 3xx response | Server down, 5xx errors, timeouts |
| Keyword | Looks for a word that should (or should not) appear on the page | Blank pages or error pages that still return 200 |
| SSL certificate | Days left before the certificate expires | Browser security warnings |
| DNS | Records resolve to the expected values | DNS mistakes, hijacks |
| Domain expiry | Registration end date | The whole site vanishing |
| Ping (ICMP) | The server answers on the network | Host or network failure (not app errors) |
| Port (TCP) | A port accepts connections, such as 443, 3306 or 25 | Database, mail or SSH services down |
| Heartbeat (cron) | Your job pings the monitor and silence triggers an alert | Failed backups, cron jobs, queues |
| Synthetic transaction | A headless browser logs in or checks out | Broken flows that still return 200 |
| Real user monitoring (RUM) | Real visitors’ browsers report load times and errors | Slow regions, partial outages |
Step 3: Set the Check Interval and Locations
For a business site, check every 1 minute. Hobby sites can live with 5 minutes. Also, run checks from at least two regions, ideally near your main audiences. That way, a network problem in one region does not hide a real outage elsewhere.
Step 4: Confirm Failures Before Alerting
False alarms train people to ignore alerts. So, configure the monitor to alert only when two or more locations agree. Another option is to wait for two failed checks in a row. Most tools call this confirmation or retry logic.
Step 5: Route Alerts to a Human Who Can Act
Email alone is too slow at 3 a.m. Instead, send critical alerts to SMS, a phone call, Slack or Telegram. Then add an escalation rule for alerts nobody acknowledges within 10 minutes. Equally important, write a short runbook: who checks logs, who talks to customers and who can roll back a deploy.
Step 6: Publish a Status Page
A public status page answers “is it just me?” before your inbox fills up. Most monitoring tools generate one automatically from your monitors. Update it during incidents, even if the update is only “we are investigating”.
Step 7: Review Your Uptime Report Every Month
Finally, track uptime percentage, number of incidents, MTTR and the slowest response times. Compare them against your target and your host’s SLA. If the same cause shows up twice, fix the root cause rather than the symptom.
Best Uptime Monitoring Tools: SaaS vs. Self-Hosted
You can rent monitoring as a service or run your own. Here is how popular options compare (plans checked October 2026):
| Tool | Type | Free tier | Fastest check |
|---|---|---|---|
| UptimeRobot | SaaS | 50 monitors at 5-minute checks, aimed at hobby and non-profit projects | 15 seconds on paid plans |
| Better Stack | SaaS | 10 monitors at 3-minute checks plus a status page | 30 seconds on paid plans |
| Pingdom | SaaS | No free plan (30-day trial) | 1 minute |
| Uptime Kuma | Self-hosted, open source (MIT) | Free, you host it | 20 seconds |
| Healthchecks | Self-hosted, open source | Free, you host it | Built for heartbeat and cron monitoring |
The trade-off is simple. SaaS tools are quick to start and monitor from many regions. In contrast, self-hosted tools cost less at scale, keep your data private and remove per-monitor limits. Uptime Kuma alone has about 90,000 GitHub stars. That popularity shows how many teams prefer to own their monitoring.
| Approach | Pros | Cons |
|---|---|---|
| SaaS monitoring | ✅ Many global locations; ✅ Nothing to maintain | ❌ Per-monitor pricing; ❌ Free tiers check less often |
| Self-hosted monitoring | ✅ Unlimited monitors; ✅ Full data control | ❌ You maintain it; ❌ It needs its own reliable server |
Hosting Uptime Guarantees: What 99.9% Really Pays
An uptime guarantee is a refund policy, not a promise that nothing will break. Take AWS EC2 as an example. If monthly region-level uptime falls below 99.99%, you get a 10% service credit. Below 99.0%, the credit rises to 30%. Only below 95.0% do you get 100% back.
Notice what that means. The credit is a percentage of your hosting bill, not of your lost sales. Most hosting SLAs also exclude scheduled maintenance. On top of that, you usually have to file the claim yourself. Therefore, your own monitoring data is the evidence you need.
Pro Tips to Keep Your Uptime High
Tip 1: Monitor From Outside Your Own Server
A monitor running on the same server as your site goes down with it. Always run your uptime checks from a separate server or service.
Tip 2: Watch Resources Before They Run Out
CPU, RAM and disk problems usually build up for hours before a crash. Learn how to monitor website RAM and CPU usage so you can act on trends, not outages.
Tip 3: Test Updates on Staging First
Most self-inflicted downtime comes from untested changes. A staging site lets you break things where nobody can see.
Tip 4: Keep Automatic Off-Server Backups
Backups do not prevent downtime. Still, they decide how long it lasts. Set up automatic site backups and test a restore at least once a quarter.
Tip 5: Cache Aggressively
Caching lets your server survive traffic spikes it could never handle otherwise. Pair page caching with Redis object caching for dynamic sites.
Tip 6: Show a Proper Maintenance Page With a 503
Whenever you take the site down on purpose, serve a 503 status with a Retry-After header. Then Google knows the pause is temporary.
Tip 7: Remove Single Points of Failure
Use a reliable DNS provider, a CDN and a host with redundant power and network. Also, keep a second admin who can reach the server if you cannot.
Quick Uptime Monitoring Checklist
Run through this list once, then review it every quarter:
- ✅ HTTP monitors on homepage, login, checkout and API
- ✅ Keyword monitor on at least one critical page
- ✅ SSL and domain expiry alerts set 14+ days ahead
- ✅ 1-minute checks from two or more regions
- ✅ Confirmation before alerts fire
- ✅ SMS or chat alerts with escalation
- ✅ A public status page
- ✅ A monthly uptime report with MTTR
Monitor Uptime and Stay Online With xCloud
Good monitoring starts with good hosting. With xCloud Managed Hosting, the platform handles server setup, security updates and backups. So, you spend less time firefighting and more time building.
Inside the dashboard, xCloud gives you two views that matter for uptime:
- Server Monitoring: RAM, CPU and disk usage, an uptime overview, per-site resource reports and the top CPU and RAM processes. 👉 Follow the guide to monitor server resource usage with xCloud.
- Site Insights: live PHP, MySQL and traffic data, including status codes and slow queries. 👉 See how to monitor website performance with Site Insights.
For external checks and a public status page, you can deploy Uptime Kuma hosting on xCloud in one click. It supports HTTP, TCP, DNS, ping and WebSocket monitors, plus certificate expiry alerts. 👉 Follow the step-by-step guide to deploy Uptime Kuma with xCloud.
Here is our honest advice: put Uptime Kuma on a different server from the sites it watches. Otherwise, one outage takes down both your site and the alarm that should report it.
Need something else? The xCloud catalog includes dozens of one-click monitoring apps, such as Grafana, Gatus and OneUptime.
Ready to stop finding out about downtime from customers? See xCloud pricing and set up your first uptime monitor today.
Track Your Uptime Today Before Your Customers Do
Uptime is a single number. Even so, it reflects your hosting, your deploy habits and how fast your team responds. 99.9% is a fair baseline for most sites. However, the real goal is shorter outages that you catch first.
This week, set up HTTP and SSL monitors on your most important pages, add a second check location and send alerts to your phone. Next month, read your first uptime report and fix whatever caused the biggest dip.
If you have found this blog helpful, feel free to subscribe to our blogs for valuable tutorials, guides, knowledge and tips on web hosting and server management. You can also join our Facebook community to share insights and engage in discussions.
Frequently asked questions
What is uptime in simple words?
Uptime is the time your website or server is online and working. People usually show it as a percentage over a month or a year, such as 99.9%. The higher the number, the less time visitors found your site unavailable.
Is 99.9% uptime good enough?
For most business websites, yes. It allows about 43 minutes of downtime a month. Stores and SaaS products with heavy traffic should aim for 99.95% or 99.99%.
How do you calculate uptime percentage?
Subtract downtime from total time, divide by total time and multiply by 100. For example, 45 minutes of downtime in a 30-day month gives (43,200 − 45) ÷ 43,200 × 100 = 99.896%.
What is the difference between uptime and availability?
Uptime measures whether a system is running. Availability measures whether users can actually complete their task, such as logging in or checking out. A server can show 100% uptime while a broken checkout makes the site unavailable.
Does planned maintenance count as downtime?
For your visitors, yes. Many hosting SLAs still exclude scheduled maintenance from their uptime calculation. To protect SEO, return a 503 status with a Retry-After header during maintenance.
Does website downtime affect Google rankings?
Short outages usually do not. However, server errors that last for days make Google crawl less and can drop pages from the index. Serve a 503 during downtime and fix the cause within a day or two.
How can I monitor my website uptime for free?
UptimeRobot offers 50 free monitors with 5-minute checks for personal and non-profit projects. Better Stack’s free plan includes 10 monitors with 3-minute checks. For unlimited monitors, self-host the open-source Uptime Kuma on a separate server.
My site keeps going down at night. What should I check first?
Start with the server logs and resource graphs for the exact time of each outage. Night-time crashes often come from backups, cron jobs or bot crawls that max out CPU or RAM. Then move heavy jobs to quieter hours. If usage still stays near its limit, upgrade the server.