Live data asset
Live uptime benchmarksreal probe data from the fleet
Live fleet-wide uptime, SSL certificate expiry, page-speed, broken-link coverage, form-submission, and checkout-failure numbers across every site SiteGuardian monitors. Six independent probe families; cite-as URLs on every figure.
Quick answer
What fleet uptime looks like right now.
Every site SiteGuardian monitors gets a GET probe every five minutes — and four further probe families on their own cadences (4-hourly page-speed, daily SSL, 2-daily broken-link, hourly form-submission, hourly checkout-submission). This page folds the resulting rows into a rolling 30-day, fleet-wide dataset — aggregate uptime, response latency, SSL expiry buckets, form and checkout-failure pass rates, daily uptime trend, and the freshest probe outcomes. The figures are live; the dataset is public; every number is citeable.
What is on this page?
A fleet headline strip with rolling 24h / 7d uptime, the count of sites SiteGuardian is currently monitoring, the total number of probes in the rolling 30-day window, the average page-speed total load across successful probes, the SSL bucket counts (valid / expiring / expired / broken) and the "% of sites with expired or expiring SSL" figure, the form-watch pass rate, and the checkout-failure pass rate. A 30-day daily-uptime trend chart. The 50 most-recent probe outcomes, anonymised to hostname. A per-site disclosure note. A methodology aside and an FAQ.
How is the data collected?
Six independent cron pipelines feed this page, each with its own cadence and its own row kind. The uptime cron (running every five minutes, with the shared CRON_SECRET auth) issues a GET against every active site and writes a CheckRun row with the status code, latency, ok/fail outcome, and timestamp. The page folds the result rows back through the public endpoint at /api/research/uptime-benchmarks.
Can I pull the raw data?
Yes — the same JSON the page renders is published at https://siteguardian.app/api/research/uptime-benchmarks. It carries a 45-second cache ceiling and open CORS so a script or a journalist’s spreadsheet can refresh it on demand.
Live benchmark data
Methodology
How the numbers on this page are produced.
Six probe families feed this page on independent cron schedules. The uptime probe runs every five minutes — every active site gets a GET request on a per-site cron schedule, and a CheckRun row is appended with the HTTP status code, the measured latency in milliseconds, and a boolean ok flag (true for any 2xx or 3xx, false otherwise). The page-speed probe runs every four hours. The SSL probe (daily at 09:00 UTC) opens a TLS handshake against every site and writes an SslCheck row carrying daysUntilExpiry plus an ok boolean. The broken-link scanner runs twice daily, walking the site for outbound 404s. The form-watch probe runs hourly at :10 per site with a configured formWatchPath. The checkout-failure probe runs hourly at :20 per site with a configured checkoutPath. Cadences are configured in polsia.toml; writes go through their respective cron routes.
The figures on this page fold those rows into rolling 24-hour, 7-day, and 30-day windows using the same reducer as the dashboard’s site-summary cells — same two-decimal rounding, same edge-case handling (a quiet, pre-probe day renders as 100% uptime with zero total probes so the bar never lies).
SSL bucket rule: the headline folds one row per active site — the freshest SslCheck in the 30-day window, picked in-memory after the route fetches rows ordered by checkedAt desc. Bucket boundaries mirror the per-site pickAlertKindForCert picker in src/lib/business/ssl.ts: daysLeft ≤ 0 ⇒ expired; ok === false ⇒ broken (invalid cert); daysLeft in 1..14 and ok ⇒ expiring; otherwise valid. Sites with no SslCheck row in the window are not counted in any bucket.
Anonymisation rule: each recent-outcome row carries only the hostname derived from the site URL — the explicit customer label and full URL are not surfaced on this public page. Site.userId is never read by the API endpoint, so a paying-customer identifier cannot leak through this surface even by accident. The SslCheck projection reads only id / siteId / checkedAt / daysUntilExpiry / ok — no issuer, validFrom, validTo, expiresAt, or Site row.
Per-site surfacing is intentionally out of scope today. The follow-up adds a Site.publicBenchmark boolean column, a dashboard toggle, and a where-filter on the endpoint so a row only surfaces when its operator has explicitly opted in.
Frequently asked
How to read — and cite — this page.
The questions reporters, indie developers, and SMB operators ask about the live benchmark.
How is uptime % computed?
Every site SiteGuardian monitors gets a GET probe every five minutes. A probe is "ok" when the response is a 2xx or 3xx; everything else — 4xx, 5xx, timeout, network failure — counts as a fail. Uptime % over a window is (ok probes / total probes) × 100, rounded to two decimal places — the same math the dashboard uses so a number pasted from one surface matches the other.
What's the observation window?
Every figure on this page covers a rolling 30-day window ending at the moment the API last responded. The headline strip surfaces three cuts — 24-hour, 7-day, and 30-day — so a reader can see whether the last 24 hours are typical of the week, or whether a recent incident pulled the daily number down. SSL bucket counts, form-watch pass rate, and checkout-failure pass rate fold the same 30-day window across their respective probe families.
How often are these numbers refreshed?
Six probe families feed this page on independent cron schedules: a 5-minute GET probe writes CheckRun rows it surfaces in uptime/per-trend tables; a 4-hourly page-speed probe; a daily 09:00 UTC TLS cert probe; a 2-dayly outbound-link scan; an hourly-at-:10 synthetic form-submission probe; an hourly-at-:20 synthetic checkout-submission probe. The page re-fetches the API every 60 seconds and the public API has a 45-second cache ceiling, so a citation that re-pulls will see fresh numbers within roughly a minute of the next probe.
Can I cite this page?
Yes — that is the point of it. Every headline stat carries a "Cite as:" block and a copy-to-clipboard button. Each citation resolves to a fragment-stable URL on this very page (e.g. /research/uptime-benchmarks#uptime-24h or /research/uptime-benchmarks#sites-expired-expiring-ssl-30d), so an article citation lands a reader on the figure being referenced, not a generic homepage.
What percentage of monitored sites have an expired or expiring SSL certificate right now?
See the figure at #sites-expired-expiring-ssl-30d on this page. It reads the freshest SslCheck row per active site over the rolling 30-day window and folds three at-risk buckets into one ratio: expired (daysLeft ≤ 0), expiring (daysLeft in 1..14 and ok), and broken (ok === false, future-dated expiry). The denominator is the count of sites for which at least one SslCheck row landed in the window. Bucket boundaries mirror the per-site pickAlertKindForCert picker in src/lib/business/ssl.ts so the fleet headline and the per-site dashboard card agree.
Why does the page show aggregate fleet numbers but not per-site rows?
SiteGuardian monitors sites whose operators did not necessarily intend to publish them in aggregate. Today's page surfaces fleet-wide numbers only — the per-site response-time table will land behind an explicit publicBenchmark opt-in toggle on each registered site, and will only show rows whose operator has flipped that toggle on.
What's the difference between this page and /status/<siteId>?
/status/<siteId> is the public status page for a single registered site, scoped to that site only. /research/uptime-benchmarks is the aggregate, fleet-wide benchmark — useful when you want to reference a figure about "what uptime looks like across the fleet" rather than about any one site.
Run the same probe against your own site
If these figures are landing for the first time, run one against your own URL.
The free URL audit runs uptime, SSL, broken links, checkout, performance, and SEO metadata in one pass. Under thirty seconds. The probe that backs the headline figures on this page is the same probe the audit runs against your URL.
Stay updated
Want us to email you when a new benchmark is published?