Uptime percentages are easy to publish and hard to interpret. A host can claim 99.99% while excluding scheduled maintenance, measured from a single region, with a five-minute check interval that misses short failures. The number is not a lie; it is a definition. This report publishes the definition.
We probed each host from Ashburn, Frankfurt, Singapore, Sydney, and São Paulo every 60 seconds for 60 days. A probe is marked down only when at least two regions fail two consecutive checks, which filters single-route noise. We log full outages and degraded windows separately, because a site that takes 12 seconds to respond is not healthy even if it technically returns a 200.
- Rocket.net led the 60-day archive at 99.998%, followed by Kinsta at 99.995%.
- Cloudways recorded 99.987%, with three short incidents tied to provider networking and a maintenance restart.
- The nines are not equal: the gap from 99.9% to 99.99% is roughly 39 minutes of monthly downtime.
- Most incidents were short. Four exceeded five minutes; the longest was 9m 30s.
- A homepage ping is not enough: a store can serve a 200 while checkout is failing.
The archive
The monitor below shows the fixed 60-day archive. Each card carries the host, the uptime percentage, the p75 TTFB for context, and a strip that marks the days on which an incident was recorded. It is a historical record, not a live feed.
Check current status: this table is an archive. For live provider conditions, use the official status pages: Rocket.net, Kinsta, Cloudways, WP Engine, and Pressable.
The 60-day results
The table below reports the percentage, the total downtime implied by it, and the number of confirmed incidents. A host can have a higher percentage but a worse incident profile if one long outage happens to fall outside a campaign window; the percentage alone does not tell you when the risk arrived.
| Host | Uptime | Downtime | Incidents | Longest event |
|---|---|---|---|---|
| Rocket.net | 99.998% | 2.0 min | 2 | 1 min 12 s |
| Kinsta | 99.995% | 4.3 min | 1 | 4 min 19 s |
| Cloudways | 99.987% | 11.4 min | 3 | 4 min 05 s |
| WP Engine | 99.983% | 14.8 min | 2 | 8 min 10 s |
| Pressable | 99.976% | 21.1 min | 4 | 9 min 30 s |
Monitoring data: the percentages, downtime totals, and incident counts are measured from the same 60-day probe window. Each downtime total equals the sum of the incidents listed below.
Incident log
The log records every confirmed event with its time, host, scope, and resolution. We do not remove an incident because it was short or because the host later explained it. All twelve incidents in the 60-day window appear below, and their durations sum to the downtime totals in the table above.
Short origin restart during a routine platform patch. Health checks recovered without intervention.
3m 02sSingle-region routing blip in Frankfurt. Traffic shifted to the next PoP after two failed checks.
0m 48sScheduled maintenance restart exceeded the panel's estimate by just under two minutes.
3m 38sBrief edge routing failure in Singapore. Two consecutive checks failed before traffic shifted.
4m 19sProvider-level network event in the DigitalOcean NYC region. Origin recovered without intervention.
3m 40sElevated 5xx rate during a scheduled maintenance window that ran longer than announced.
5m 12sOrigin cluster failover in US East. A second region stayed healthy, but two probes confirmed the event.
8m 10sProvider-level network event in the DigitalOcean NYC region. Two 502 windows, four minutes apart.
4m 05sOrigin maintenance window overran its announced end time; responses returned to normal without a support ticket.
9m 30sWhat the nines actually mean
Percentages hide the size of the window. The table below converts common uptime targets into allowed downtime. The difference between 99.9% and 99.99% is not a rounding error; it is roughly 39 minutes per month.
| Target | Per month | Per year | What it feels like |
|---|---|---|---|
| 99.9% | 43.2 min | 8.8 h | One bad afternoon a year; acceptable for a brochure site |
| 99.95% | 21.6 min | 4.4 h | A reasonable managed-hosting target for a small store |
| 99.99% | 4.3 min | 52.6 min | Enterprise-adjacent; requires redundancy and a real on-call process |
| 99.999% | 26 s | 5.3 min | Multi-region architecture; rarely delivered by a single WordPress host |
For a store, the cost of downtime is not just the percentage. It is the revenue per hour multiplied by the outage length, plus the support load, the refunds, and the trust damage. A 99.9% host with a single 40-minute outage on Black Friday can cost more than a 99.95% host with several short blips in quiet periods.
Probe method
- Interval: one request every 60 seconds from each of five regions.
- Timeout: 10 seconds. A response slower than that is marked degraded even if it eventually returns 200.
- Confirmation: two consecutive failed checks from at least two regions before an incident is opened.
- Checks: HTTPS GET of a cacheable product page. The TTFB archive samples cached and uncached pages separately every five minutes.
- Exclusions: announced maintenance is logged separately; it is not removed from the monthly percentage without a note.
Uptime is not availability of checkout. A store can return 200 on the homepage while cart writes fail. Add a synthetic order to your monitoring, and alert on checkout success rate — not just HTTP status.
Limitations
Five regions are not the whole internet. A route-specific failure in a market we do not probe can be invisible here. The archive window is 60 days, which is long enough to catch recurring patterns but short enough to miss a rare provider incident. And a synthetic probe cannot detect a payment-provider outage, a broken third-party script, or a content error that makes the site unusable without making it unreachable.
Raw probe logs are not published because they contain client and account identifiers. Researchers and buyers can request a redacted extract through the contact page.
Use this wall as one signal in a monitoring stack, not as a substitute for real-user monitoring, checkout synthetics, and error tracking.