Every host advertises high uptime. Few explain what happens when the promise is broken. Choosing hosting for reliability means looking past the headline percentage to the things that actually decide whether your site stays up, how fast you can recover, and what you get when something goes wrong. This guide gives you a checklist you can apply to any provider without relying on brand rankings, which age quickly and are often paid placement.
Start with what "uptime" means to the host
The percentage on a sales page is a marketing figure unless it is backed by a written service level agreement (SLA). Find the SLA document, not the landing page, and read these parts.
How downtime is defined
Look for the exact definition. Common weaknesses:
- Only complete network or server unreachability counts. A server that is up but returning 500 errors, or a database that is down, may not count.
- Downtime is measured by the host's own monitoring, from inside its own network.
- Short outages under a certain length (for example, anything below a few minutes) are ignored. Check the stated threshold.
What is excluded
Almost every SLA excludes some categories:
- Scheduled maintenance, sometimes with no cap on how much of it there is.
- Problems caused by your code, plugins, or account resource overuse.
- DDoS attacks, "force majeure," and upstream provider failures.
- Anything on a free trial or promotional plan.
Excluded time is real downtime for your visitors even if it does not count for the SLA.
The remedy
Most SLAs offer service credits, not refunds, and not compensation for lost revenue. Check:
- Is the credit a fraction of one month's fee? That is nothing compared to a lost sale.
- Do you have to file a claim, and within what window?
- Are credits capped?
To translate a percentage into real time, use the SLA uptime calculation guide and uptime percentages explained. As a quick check: 99.9% over a 30-day month allows about 43 minutes of downtime, and 99.99% allows about 4 minutes.
Check the track record independently
Don't rely on the host's claim; look for evidence.
- Public status page. Does the provider publish one? Does it show past incidents with dates and explanations? A host with no incident history is either flawless or not telling you.
- Post-incident reports. Providers that publish honest root-cause write-ups tend to fix root causes.
- Independent monitoring. The best evidence is your own. Before moving a production site, rent the cheapest plan, host a small test page, and watch it with an external monitor for a few weeks. SiteDownCheck's free Uptime Monitor can do this with 3 monitors and 5-minute checks, and alerts you to failures. Our website down for everyone or just me guide helps you tell a host outage from a local one.
- Community reports. Search for outage threads about the specific data center you'd be placed in. Read them for patterns, not single complaints.
Support: test it before you need it
Support quality is invisible until an incident, so test in advance.
- Channels and hours. Is support 24/7? Does it include live chat or phone, or only tickets? Is out-of-hours support limited to the highest tier?
- Response and resolution time. Look for a stated target. Then open a pre-sales question with a technical edge ("What PHP-FPM settings are applied to my account?" or "Can I restore a single database from yesterday's backup?") and see who answers and how quickly.
- Who answers. Scripted first-line replies that don't read your question are a warning sign. Competent staff give specifics.
- Escalation path. On managed plans, can you reach a system administrator? On unmanaged servers, what is and isn't supported?
Backups: the thing that decides your worst day
Ask exactly how backups work, because "backups included" varies enormously.
| Question | Why it matters |
|---|---|
| How often are backups taken? | Defines how much data you lose in a disaster |
| How long are they retained? | A hacked site discovered after two weeks needs a backup older than that |
| Where are they stored? | Backups on the same server or account die with it |
| Are databases included, and consistently? | A file-only backup restores a broken site |
| Who can restore, and how fast? | Self-service restore beats a ticket queue |
| Can you download them? | Lets you keep an independent copy |
Whatever the host does, keep your own off-site copy. A nightly dump and file sync to a separate provider is cheap insurance. Then test a restore to a scratch environment at least once. An untested backup is a hope, not a plan. Read WordPress site hacked recovery for why retention and clean copies matter.
Resource limits and the word "unlimited"
"Unlimited" almost always has an acceptable-use policy behind it. Look for the real limits:
- CPU and RAM per account, and what happens when you hit them (throttling, 503/508 errors, or suspension).
- Entry processes or concurrent PHP workers. This caps how many requests run at the same time. A small number means traffic spikes produce errors, not slowness. See fix 503 service unavailable.
- Inodes (file count), disk I/O, and database connections.
- Bandwidth and any overage behavior.
- Fair-use language about "excessive" usage with no number attached. Ask support what the effective ceiling is.
Resource isolation is where shared plans differ most from virtual servers. Our VPS vs shared hosting reliability guide goes deeper.
Infrastructure details worth asking about
- Data center location. Closer to your visitors means lower latency. Use the Website Speed Test from your target regions on a trial site.
- Redundancy. Power, network uplinks, and storage. Does the provider describe failover, or only say "enterprise-grade"?
- Network. Check who operates the network with the ASN Lookup or IP Lookup on a trial server's address. The Website Hosting Checker shows who hosts any site, handy for checking what competitors or reviewers actually use.
- DDoS handling. What is included, and what happens to your site during an attack?
- Software currency. Supported PHP versions, TLS configuration, and how fast security patches are applied.
- Staging and rollback. Can you test changes before they touch production, and undo them quickly?
- Email. Whether mail is on the same server as the website matters during an outage and for deliverability. Many sites are better served with separate mail hosting.
Plan for the host failing anyway
No host eliminates risk, so design for it:
- Put DNS with a separate provider so you can repoint quickly. See change nameservers without downtime.
- Keep TTLs reasonable on key records. See TTL explained.
- Use a CDN so cached pages keep serving during short origin outages. See CDN explained.
- Keep a documented, rehearsed migration plan.
- Publish a status page so you can communicate during incidents.
- Monitor from outside, with alerts to more than one channel.
A short decision checklist
Before you pay, you should be able to answer yes to most of these:
- I read the SLA's definition of downtime, exclusions, and remedy.
- I found at least one independent source of historical reliability, or ran my own test.
- I know the real CPU, memory, process and inode limits for my plan.
- Backups are off-server, retained long enough, and I tested a restore.
- Support responded competently to a technical pre-sales question.
- I can leave: data export is possible, DNS is not locked to the host.
Next steps
- Check what a site runs on with the Website Hosting Checker.
- Start an independent trial with the Uptime Monitor.
- Compare options in VPS vs shared hosting reliability.
- Understand the numbers in SLA uptime calculation.
- Read uptime monitoring for small business.
FAQ
Is a 99.9% uptime guarantee good enough?
It depends on what the site earns per hour and how the SLA defines downtime. 99.9% allows around 43 minutes per month, and exclusions can add more. Read the fine print and keep your own monitoring.
Does a higher price mean better uptime?
Not automatically. Price correlates with resources and support, but reliability depends on architecture and operations. Verify with a trial and independent monitoring.
Should I use the host's backups alone?
No. Keep an independent off-site backup and test restores. Host backups can be on the same infrastructure, short-lived, or unavailable during the very incident you need them for.
How can I test a host before moving my site?
Buy the smallest plan, put a test page on it, and watch it with an external monitor for a few weeks. Also open a technical support question to see how the team responds.
Get notified when this guide updates
Plus occasional practical tips on uptime and monitoring, nothing else. Unsubscribe anytime.
This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.