How to Evaluate a Web Host & Pick The Best One

To evaluate a web host, you ignore the marketing and test the things that bite you later: the CPU, memory, and IO limits hiding behind "unlimited," how oversold the servers are, what the uptime guarantee pays out, the renewal price rather than the intro price, support response time, backup policy, and how hard it is to leave. The host's quality matters more than the plan tier, and most of these you can verify yourself before you pay a cent.

This is the full checklist, with what good and bad look like for each criterion and exactly how to test it before you buy. It pairs with our broader guide on which hosting type is best for small websites, which summarizes these checks inside a wider decision. Here we go deeper: every line item gets a verification step you can run. It is built from what experienced administrators on Hacker News and hosting forums repeatedly warn newcomers about.

What is really hiding behind "unlimited" hosting?

No plan is unlimited. "Unlimited" storage and bandwidth almost always sit on top of undisclosed caps on CPU time, memory, disk operations, and inodes, the count of individual files you can store. The binding limits live in the terms of service, not the headline, and knowing where to find them is half the work of evaluating any host.

A WordPress install with a few plugins can hold tens of thousands of files, so an inode cap that sounds huge can be closer than you think. CPU and memory caps are what throttle you under traffic, even when your disk usage looks fine. As one Hacker News commenter put it, those unlimited claims "are false because of other rules around inode limits and cpu limits" (Hacker News).

How to verify it before you buy:

• Open the plan's terms of service and acceptable use policy, not the sales page, and search for "inode," "CPU," "entry processes," "I/O," and "memory."
• If those numbers are not published anywhere, ask presales for them in writing. A host that hides its limits is telling you something.
• A clear, stated cap is better than a vague "unlimited." You want a number you can plan around. Our explainer on what unlimited hosting really means walks through where these caps usually sit.

How can you tell if a host is overselling?

Hosts sell more capacity than they physically have, betting that not everyone uses it at once. Every provider does this to some degree, but heavy overselling is why a cheap server feels sluggish for no obvious reason. What you are checking is not whether a host oversells, it is how badly, and on a VPS you can measure this directly.

"Every provider oversubscribes," one administrator wrote, because they "do not expect and cannot handle 100% utilization by their subscriber base" (Hacker News). That is the baseline. The tell for the abusive end of it is CPU steal time, the share of time your virtual CPU spends waiting on a busy physical CPU. As another commenter described it, steal time is "the percentage of time a virtual CPU waits for a physical CPU from the hypervisor while it is busy serving another VM" and a high reading is "strong indication you are being ripped off CPU" (Hacker News).

How to verify it:

• On a Linux VPS, run top and look at the %st column, or run vmstat 1 and watch the st field. Sustained steal time above a few percent under normal load means you are sharing a core with noisy neighbors.
• During a trial, run a short CPU benchmark twice, once at a quiet hour and once at peak. A big gap points to contention.
• Prefer plans that advertise dedicated vCPU cores over "burstable" or "shared" cores if consistent performance matters to you.

What does an uptime guarantee promise you?

A "99.9% uptime SLA" is not a promise your site stays up. It is a promise to credit your account if it does not, and the credit is usually small. A service level agreement (SLA) is a refund formula, not a reliability mechanism, and the fine print decides how little it pays and what does not count.

As one commenter explained bluntly, "an SLA of 100% just means your account will be credited for any downtime. It doesn't mean that the company guarantees 100% uptime" (Hacker News). The math is unforgiving on your side: 99.9% allows roughly 8.7 hours of downtime a year, and even then you typically have to notice the outage, open a ticket, and claim the credit yourself.

How to verify it:

• Read the SLA document and note the exclusions: scheduled maintenance, network issues "outside our control," and attacks usually do not count.
• Check whether credits are automatic or claim-only. Claim-only credits are designed to expire unclaimed.
• Treat the percentage as the host's stated goal, then sanity-check it against an independent status-page history and recent user reports. Look at how the host communicates during an outage, which tells you more than the number.

How do bandwidth, egress, and overage fees catch people out?

On usage-based and cloud plans, the cost that surprises people is egress: the fee to move data out of the host. It can be marked up steeply, and many providers have no hard spending cap, so one bad month, a traffic spike or a misconfigured backup loop, becomes a large bill with no automatic brake.

One widely shared account described being charged thousands of dollars for transfer that "costs $180 elsewhere" (Hacker News). Getting data in is usually free, getting it out is where the meter runs, and the absence of a spending cap means that meter has no ceiling.

How to verify it:

• Find the per-gigabyte egress rate and the included transfer allowance, then estimate your monthly outbound traffic and multiply.
• Ask whether you can set a hard spending cap or a billing alert. If the answer is only "alerts," understand that an alert does not stop the charge.
• For a small or flat-rate site this rarely bites, but on metered cloud it is the single most common cause of a shock invoice.

What backup policy should you require, and what should you do yourself?

Require that the host takes regular off-site backups, then assume those backups will fail you at the worst moment and keep your own copy somewhere the host does not control. A host's backup feature is a convenience for small mistakes, not your safety net, because it disappears exactly when the host itself is the problem.

This advice shows up in nearly every hosting horror story. "Always make backups," one administrator wrote. "If a provider goes deadpool on you all of the sudden, you should always have fresh backups in a remote site" (Hacker News). The worst cases involve accounts suspended without warning and the owner locked out of their own data (Hacker News).

How to verify it and protect yourself:

• Confirm backup frequency, retention period, and whether restores cost extra or count against your storage quota.
• Test a restore during your trial. A backup you have never restored is a guess.
• Set up an independent off-site copy on day one: a scheduled rsync or a database dump to separate storage in a different provider. If your only copy lives with your host, you do not have a backup, you have a hope.

How do you test support before you depend on it?

When something breaks, support quality matters more than almost any spec, especially if you are not a server expert. The way to evaluate it is to use it before you are paying for it. Send a specific presales question, time the response, and judge whether the answer came from someone who understands the platform or from a script.

"Your biggest concern should be accessibility to support that actually knows how to do the things you're doing," one veteran advised a beginner (Hacker News). Support reality varies widely even among well-regarded hosts: in one comparison, a user called OVH response times "atrocious, multiple days of waiting," while opinions on Hetzner split between "cold and dismissive" and "I ask technical questions and they respond with correct technical info" (Hacker News). The lesson is to test for yourself rather than trust a reputation.

How to verify it:

• Open a presales ticket with a specific technical question, ideally one only a knowledgeable team can answer well, and note the response time and depth.
• Check what channels exist and their staffed hours. "24/7 support" that is chat-only and outsourced is different from engineers you can reach.
• Search recent forum threads for the host's name plus "support" to see whether your trial experience is typical.

Renewal price or intro price: which one are you choosing?

Decide based on the renewal price, the rate you will keep paying, not the sign-up discount. The headline number on budget hosts is frequently a teaser that renews at several times the rate, so a plan that looks cheap in year one can be the expensive option by year two. The discount is a customer-acquisition cost, and you pay it back on renewal.

How to verify it:

• Find the renewal price on the plan page or in the terms. It is often in small print or a footnote next to the intro rate.
• Calculate the multi-year cost at the renewal rate, not the promo rate, and compare hosts on that basis.
• Watch the billing term tied to the cheapest intro price. A two-dollar rate often requires paying three years upfront, which front-loads your risk.

Do you get root access and software freedom?

Check whether the plan gives you root access and lets you install and run what you want, because the lack of it is the most common reason people outgrow shared hosting. Shared plans lock down what you can install and frequently kill long-running processes, which breaks background workers, custom runtimes, and anything beyond a standard website.

"Most shared hosts have daemons that kill long running processes," one developer explained, whereas on a VPS "you can install whatever you want" (Hacker News). If you need a specific language version, a queue worker, or a service that stays running, you need a VPS or cloud plan, not shared hosting.

How to verify it:

• Confirm whether you get full root or sudo access, or only a control panel.
• Ask whether long-running and background processes are allowed, or killed by a process reaper.
• Check the available operating systems and whether you can run your own software versions. If the answer is "only what we preinstall," that is a hard ceiling.

Managed or unmanaged: which work are you signing up for?

Decide honestly whether you want to be the system administrator, because that choice changes which hosts even make sense. An unmanaged plan is cheaper and hands you the security updates, configuration, and troubleshooting. A managed plan does that work for you at a higher price, which is the right trade if you are not comfortable running a server.

Neither is better in the abstract. For a beginner, the same Hacker News thread on support accessibility leans toward managed, because reachable expertise matters more than saving a few dollars when you are learning (Hacker News). Some platforms blur the line and offer managed cloud VPS hosting, including the one we run at Carpathian, but managed is not automatically the right answer: if you want to learn server administration or already know it, an unmanaged box gives you more control for less money.

How to verify it:

• Read exactly what "managed" includes: OS patching, security hardening, backups, and incident response, or only hardware and network.
• For unmanaged, confirm you are comfortable handling updates and breakage yourself, including at inconvenient hours.
• Match the choice to your skills and time, not to the marketing label.

How hard will it be to leave this host?

Ask how hard it is to leave before you arrive. Lock-in shows up as proprietary control panels, custom APIs your code comes to depend on, and high egress fees that make moving your data expensive. A host that makes export easy is quietly telling you it plans to keep you by being good, not by trapping you.

How to verify it:

• Confirm you can export your full data, databases, files, and configuration, in standard formats without paying a ransom in egress.
• Prefer standard tools, SSH, rsync, plain database dumps, over a proprietary panel that only exports to itself.
• Check whether the stack is portable, for example standard Linux and open-source software, so a migration is a copy rather than a rewrite. Keeping portable off-site backups, from the backup step above, doubles as your escape hatch.

What happens if your account gets suspended?

Read the acceptable use policy and understand that a host can suspend your account, and your access to your data, for a terms violation, a billing dispute, or an automated false positive. Suspension risk is the criterion people skip until it happens to them, and it is the reason the off-site backup advice is not optional.

The harshest stories involve accounts suspended without warning and owners locked out entirely (Hacker News). You will not eliminate this risk, but you can blunt it.

How to verify it and reduce the risk:

• Read the AUP for vague catch-all clauses that let the host suspend "at its discretion," and note whether they give notice before suspension.
• Keep billing current and contact information accurate, since automated billing failures are a common trigger.
• Hold an independent off-site copy of everything, so a suspension is an inconvenience rather than a loss.

Who owns this host, and does that matter?

Find out who owns the brand, because hosting quality often declines after an acquisition. A well-reviewed independent host can be bought by a holding company, run on its existing reputation, and quietly degrade as support is consolidated and infrastructure is starved. The reviews you read may describe a company that no longer exists in the same form.

The clearest documented pattern is Endurance International Group (EIG), which acquired many familiar brands. One administrator traced A Small Orange's decline after its acquisition, noting that "2014 and 2015 were riddled with major outages at both A Small Orange and HostGator" and that the service "never really recovered" (Hacker News).

How to verify it:

• Search the host's name plus "acquired" or "parent company" to find out who owns it now.
• Weight recent reviews over old ones, and look specifically for a step-change in complaints around an acquisition date.
• A long-running independent operator that still answers its own support is worth a small premium over a brand that has changed hands repeatedly.

Where are the servers, and does data residency apply to you?

Confirm where the servers physically sit, because location affects both latency and which laws govern your data. Distance to your visitors adds milliseconds, and the country a server lives in determines the data-protection and disclosure rules that apply. If you handle regulated or personal data, residency can be a hard requirement, not a preference.

How to verify it:

• Check the datacenter locations and pick one close to your audience for lower latency.
• If you have legal obligations, such as GDPR for EU residents, confirm the host can keep data in the required region and will say so contractually.
• Ask where backups are stored too, since a backup in another jurisdiction can undo your residency choice.

How do you run the whole evaluation?

Work through the checklist in this order and you will catch the problems before they cost you.

1. Write down what your site needs: traffic level, software requirements, root access, uptime sensitivity, and any data-residency rules.
2. Shortlist two or three hosts and read each one's terms of service and acceptable use policy, not just the sales page. Pull the inode, CPU, memory, egress, and renewal numbers.
3. Open a presales support ticket with a specific technical question and time the reply.
4. Take a trial or money-back window and measure CPU steal time, run a small peak-versus-quiet benchmark, and test a backup restore.
5. Confirm you can export everything in standard formats, then check who owns the host and how recent reviews trend.
6. Decide on the renewal price and your expected workload, set up an independent off-site backup on day one, and only upgrade later on a measured trigger.

If you are weighing specs rather than vendors, our guide on how to choose a VPS covers sizing the box itself. The best host tends to be the one you stop thinking about: clear about its limits, honest about its pricing, and easy to leave if it ever stops earning your trust. Evaluate for that, keep your own backups, and let the host prove it deserves to keep you.