Our Testing Methodology

Uptime matters because an offline site cannot serve visitors. This section describes uptime evaluation criteria. A monitoring claim must be tied to the host, source, and observation period that support it; this page does not establish a minimum monitoring history for every reviewed host.

Monitoring tools, check intervals, observation periods, and sample counts must be stated with the applicable host-specific evidence. No universal monitoring duration or annual sample count is established here.

Uptime Evaluation Criteria

The criteria and score bands below describe the published framework. They do not establish that a host has completed monitoring or received a score under it.

• →Overall uptime percentage over the full monitoring period
• →Number and duration of individual outage incidents
• →Longest single downtime event
• →Patterns: are outages clustered at certain times (maintenance windows, peak traffic)?
• →Response time may provide a secondary signal when comparable monitoring and Speed Index records are available for the same host

Published Uptime Score Bands

• →5.0 – 99.95% or above (less than ~4.4 hrs downtime/year)
• →4.0 to 4.9 – 99.90% to 99.94%
• →3.0 to 3.9 – 99.80% to 99.89%
• →2.0 to 2.9 – 99.50% to 99.79%
• →1.0 to 1.9 – below 99.50%

Page load speed affects user experience. The HostingDive Speed Index is a separate first-party benchmark of server response on probe sites that meet its publication requirements. Its measurements do not establish how a general review speed score was calculated.

How the Speed Index Works

• →Probe sites are checked against the standard WordPress configuration described in How We Test Hosting Speed; nonconforming probes are withheld from published figures
• →Publishable probes are measured from a fixed US cloud location in back-to-back runs; a shared vantage does not make the network path to different hosts identical
• →Time to first byte (TTFB) measures server response in the probe environment; it does not measure every part of a visitor's page-loading experience
• →The published benchmark method describes repeated warm requests summarized by median and tail response, with a separate cold reading and dated result updates

Measurement Class

First-party probe measurements and third-party field observations are different evidence classes. The benchmark method explains their scope and the withholding of nonconforming probes. No conversion from either class into a general review speed score is established on this page; an absent or withheld probe result is not a substitute score.

Single-user speed tests tell only part of the story. We also want to know how a host performs under concurrent traffic: when multiple visitors hit your site at the same time. This is especially relevant for shared hosting, where server resources are divided among many customers.

Load Evaluation Criteria

These are evaluation criteria, not a claim that each host has undergone a load test. A completed load-test claim requires its own retained test record.

• →A load-test record should identify the tool, test site, and concurrent traffic profile
• →The record should state the ramp profiles used
• →The record should state the duration at peak load
• →Response-time degradation is an evaluation criterion
• →Error rates are an evaluation criterion; a category failure requires a supporting test record
• →The record should identify the timing and conditions of the test

What Makes a Good Score

• →5.0 – Response time stays within 200% of baseline at 100 concurrent users, less than 1% error rate
• →4.0 to 4.9 – Moderate degradation (up to 300%), error rate under 2%
• →Below 3.0 – Significant slowdown or errors appear before 50 concurrent users

Great performance means nothing if you're stuck with broken hosting and no help in sight. We treat support evaluation as a first-class testing category, not an afterthought.

Support Evaluation Criteria

The criteria below do not establish a completed support test for every host. Claims about contacts or response quality require retained records for the host concerned.

• →A support evaluation should identify the contacts actually made; no universal minimum interaction count is established here
• →The record should identify the channels used, such as live chat or ticket/email
• →The record should state when contacts occurred; off-hours coverage must be evidenced
• →The record should identify the questions asked and their difficulty
• →A response-time claim requires a recorded first message and first useful response
• →Accuracy, completeness, tone, and resolution are evaluation criteria

Scoring Dimensions

• →Response time: How quickly did the first useful response arrive?
• →Accuracy: Was the answer technically correct?
• →Resolution rate: Did the agent actually solve the problem?
• →Consistency: Were results consistent across multiple interactions?

Introductory and renewal rates can differ. Pricing analysis should identify the plan, commitment, renewal terms, and verification date. The criteria below describe the published framework, not a current verified cost model for every host.

Our Pricing Methodology

• →A total-cost comparison should state its period and distinguish introductory from renewal rates
• →The comparison should identify plan charges, domains, required add-ons, and certificate costs where applicable
• →Feature-tier assumptions and differences should be stated for the plans compared
• →Commitments required for advertised rates should be identified
• →A price claim requires its source and verification date; this page does not establish a quarterly refresh for every host

Value Score

The published pricing framework considers cost alongside performance, reliability, and features. A value judgment requires evidence for the plans being compared; this framework does not establish a completed cost model or reproducible value score for every review.

Security features vary by plan. The questions below describe the published evaluation framework; they do not establish that a hands-on security audit has been completed for every reviewed host.

Security Evaluation Criteria

• →SSL/TLS: Is free SSL included? Is auto-renewal handled? Do they enforce HTTPS by default?
• →Web Application Firewall (WAF): Is a WAF available on standard plans, or only on premium tiers?
• →Malware scanning: Is automated malware scanning included? How frequently does it run?
• →Backup systems: Are daily backups automated? How many restore points are retained? Is restoration self-service?
• →DDoS protection: Is basic DDoS mitigation in place at the infrastructure level?
• →Two-factor authentication: Is 2FA available for account login?
• →Software isolation: Are shared hosting accounts properly isolated from each other?

Scoring System

The table and rating scale below describe the published review framework. They are not evidence that every category was tested for every host or that every published score can be reproduced from retained test records. The conversion from Speed Index measurements into general review speed scores is not established here.

The Rating Scale

This framework does not establish an automatic score update whenever new data arrives. A score revision requires supporting evidence and a stated review date; the separate Speed Index result dates should not be treated as proof that review scores were recalculated.

External Sources & Cross-Referencing

The Speed Index method documents a separate first-party benchmark. External publications can provide context, but naming a source here does not establish that a particular review was cross-checked or validated against it. A comparison or validation claim requires the specific source and supporting evidence.

External evidence should be linked to its original source and identified separately from first-party measurements. An independently produced score or ranking requires its own supporting evidence; a source list alone does not establish one.