Benchmark — uptime stats. Typical SaaS monthly uptime ranges, alert cadence by tier, and MTTR baselines.

99.95%

Across published SaaS reliability rollups, the median monthly uptime a SaaS vendor publishes sits around 99.95%. The headline figure is between the "three nines" (99.9%, ~43 minutes downtime / month) and the "four nines" (99.99%, ~4 minutes / month) thresholds. Most SMB tools quote three nines by default and four nines when their architecture allows it; the differential is the error-budget room. Source figures are reported by Cloudflare Radar and the Uptime Institute Annual Outage Analysis over rolling industry windows.

99.99%

The publicly published AWS, GCP, and Azure Compute SLA documents floor at 99.99% monthly uptime. Service credits are issued only when the measured window drops below the contractual threshold; the headline SLA figure is the contractual floor, not the typical observed uptime. Source figures come from each vendor's published service-level-agreement PDF — committed figures, not observed uptime.

~0.05% gap

Cloudflare Radar and ThousandEyes internet reliability reports show that externally measured uptime generally lands slightly above the vendor's contractual SLA — vendors over-deliver on average, but the contractual floor is what binds the service credit. The headline figure on a SaaS pricing page is the SLA; the figure you see in an independent probe is measured uptime. They are different numbers and should be cited on different axes.

5 min

On the public free tier of UptimeRobot, StatusCake, and HetrixTools, the probe cadence for uptime checks is 5 minutes — the floor a no-cost monitor settles at when the operator has not yet paid. Faster cadence (1-minute, 30-second) sits behind a paid tier or API-only access. Source figures are pinned to each product's free-tier pricing page as verified on the publish date noted in /pricing.

1 min (Pro)

SiteGuardian's Pro tier — the same SMB tier that ships SSL expiry + broken-link coverage + checkout-failure probes — runs at 1-minute cadence per monitor, per site. The 1-minute cadence is the differential between catching an outage before the first customer email and catching it after; the upgrade is the price of admission for that recovery clock. Source is the canonical product /pricing page; figure is an internal product claim on a public, citeable surface.

~43 min / mo

The Google SRE Workbook chapter 5 ("Practical Alerting") works the 99.9% uptime floor out to ~43 minutes of allowable monthly downtime, 4 hours and 20 minutes per quarter, ~52 minutes per week — the canonical "error budget" math that every uptime-monitoring probe is measuring against. The figure is the room, not the promise: it is the time the site can be down before an SLO breach is recorded.

45 min

On a shared-hosting tier, the median mean-time-to-recover for an outage is around 45 minutes — the operator must notice the failure, file a ticket, and wait for the host to act on it. The 45-minute window covers the host's response time but not the time it takes the operator to notice in the first place; unmonitored shared-hosting sites stack the 45-minute recovery on top of the 6+ hour customer-notice window.

15 min

On a managed WordPress / SaaS tier, the median mean-time-to-recover is ~15 minutes — the recovery clock for a vendor that runs its own probe pipeline and acts on a pre-built incident runbook. Recovery is fast because detection is fast: a probe lands every minute, the alert fires the same minute, and the runbook is a single button. The differential between this and the unmonitored self-hosted case is where active monitoring earns its keep.

6+ hours

When a self-hosted site goes dark without a probe watching, the median time-to-recover stretches past six hours. The figure mirrors the same gap the /benchmark hub cites for its `uptime-time-to-recover` stat (drawn from Usenix SOUPS operator incident-response research): the operator needs a customer to email before an alert exists, and the customer notification clock dominates the recovery clock. Active monitoring shortens the recovery clock by alerting before the customer does, not after.