30 days of uptime probes: what an availability percentage hides

Key findings

• Across 35,735 probes, 286 failed. 285 of those failures were an HTTP 403 or 404 reply; one was a timeout.
• One node, Load balancer 2, shows 95.26% availability. All but one of its 242 failures were 404 replies spread over 179 separate hours. It was never unreachable for a long stretch.
• Each node has 5,105 probes in 30 days. One probe every two minutes would give 21,600. The percentages describe the probes that ran, not every minute of the month.
• From 8 October 12:00 UTC to 13 October, five of seven nodes had no failed probes, and Pages and the edge proxy had one each.

How we measured

Every node on the status page is probed on a schedule: a Cloudflare cron trigger plus a GitHub Actions schedule that calls the same probe endpoint. Each probe stores one row with the node, the time, whether it succeeded, the response time and the HTTP status. A probe counts as failed when the reply is not a success or does not arrive in time.

The figures below come from those rows for 13 September to 13 October 2026. Response times use successful probes only. The median is the 50th percentile and p95 is the 95th. We report percentiles because averages hide a slow tail, as the Google SRE book explains in its chapter on service level objectives.

Results per node

Each node: 5,105 probes. The load balancers answer an order of magnitude slower than Pages and the edge proxy. We have not yet isolated why.

What the failures were

A 403 means the server understood the request and refused it. A 404 means it found nothing at that address (RFC 9110). Either reply proves something answered. A Cloudflare WAF rule or a routing rule can produce them, and WAF custom rules can block matching requests before they reach the service. We therefore read these as refused or misrouted probes, not as outages. The 404s and 403s also stop after 8 October, which fits a rule or routing fix rather than a capacity problem. We have not proven the cause for every row.

Why one percentage is not enough

A single availability number mixes three different things: services that were down, probes that were refused by a rule, and minutes where no probe ran. In this data set the second group is 285 probes and the third is about 76% of the possible two-minute slots. On the Pages node the longest gap between two probes was 4.6 hours. GitHub documents that scheduled workflows can be delayed or dropped under high load, which is one reason a schedule-driven probe leaves gaps.

For anyone running similar probes: store the status class and the timeout separately, count skipped runs, and publish the denominator next to the percentage.

Limits of this analysis

• The probes are synthetic and run from QTD's own scheduled jobs. They are not customer traffic and not a view from every region.
• On 24 September we deleted 10 rows we had identified as false positives. That slightly raises the reported availability.
• The cause of the 403 and 404 replies is inferred from the pattern and the reply codes, not from edge logs for every row.
• Thirty days is one month. It does not show seasonal or long-term trends.

Sources

1. Jones, Wilkes, Murphy, Smith and Beyer (eds.), “Service Level Objectives”, chapter 4 of Site Reliability Engineering, Google
2. Fielding, Nottingham and Reschke (eds.), RFC 9110: HTTP Semantics, IETF, June 2022 (sections 15.5.4 and 15.5.5)
3. GitHub Docs, “Events that trigger workflows”, the schedule event
4. Cloudflare Docs, “WAF custom rules”