Health Check Analytics: faster diagnosis from the dashboard
Standalone Health Checks, introduced last year, monitor an IP address or hostname for your origin servers and alert you near real-time if something goes wrong. The service supports fine-tuned configurations for expected codes, interval, protocols, timeout, and more, so you can target checks based on your infrastructure's specific setup. Today the feature gains analytics and event-level detail that help you get from notification to root cause faster.
Health Check Analytics lives under the Traffic tab in the Cloudflare Dashboard. When a check fails, you get an email alert within seconds. From there, the analytics view gives you both an infrastructure overview and a drill-down path to investigate the problem.
Validating the alert and narrowing the funnel
When you receive an alert, the first question is whether the notification reflects a real, persistent problem. The analytics view answers that immediately with uptime graphs per address over a selected time period. One scenario: a staging origin shows 76% uptime while production shows 100%—and below the graph, error type breakdowns show a single recurring failure: TCP Connection Failed in the staging environment.
That single frequent error narrows the search space. It points to one of two places: the staging server's ability to accept connections (including the SYN-ACK handshake), or the router between the origin and the network. Rather than digging through logs or making educated guesses, you can test the hypothesis directly and cut time to resolution.
Event log entries expose the address, response code, round-trip time (RTT), and failure reason. For a Response Code Mismatch Error, the event now also includes the expected code and the received one, so you don't have to pull up a Health Check config that may have been set up months ago.
Drilling into per-request timing
Uptime alone doesn't tell the whole story. A service can be available but slow enough to push users elsewhere. The event log includes a waterfall view that breaks down where time is spent in each checked request, making the timing data easier to interpret.
The waterfall breaks a request into four components:
- TCP connection time — time to establish the initial connection, in dark blue.
- TLS handshake time — the cryptographic handshake for HTTPS, in light blue.
- Time to first byte (TTFB) — time from connection establishment until the first byte arrives, in dark orange.
- Remaining load time — the portion of total RTT after this, in light orange, which reflects content download time. TTFB subtracted from RTT shows how much of the load was spent fetching page content.
Those measurements give actionable signals. Slow TCP connection time suggests serving content closer to users — geo-distributed availability or Anycast can reduce both connection set-up and TLS handshake time since each round trip is shorter. A low TTFB but large gap to full RTT implies the page weight itself is the bottleneck; server-side compression or removing unnecessary content would help. A regression in any of these metrics can also point to an external library introduced in a release.
Regional perspective
Cloudflare's network spans over 200 cities in 90+ countries, but Health Checks don't run from every data center. Users select between one and thirteen regions to probe from. The analytics view also compares uptime, RTT, and waterfall timing across regions, so a check run from Western North America and one run from India can reveal regional performance differences on the same address.
A user comparing two regional waterfalls can confirm that page load time and total RTT are better from Western North America than India. That tells you not just that the service is degraded in a region, but which phase of the request is slower there.
How many probes per check?
Understanding the log output requires knowing how many requests a Health Check actually generates. Each region you select uses not one but three probing locations. For example, a check configured from two regions — Western North America and South East Asia — at a ten-second interval will hit your origin six times every ten seconds, not two. Across the maximum of thirteen regions, expect 39 requests per configured interval.
Multiple probes per region exist to keep the health signal honest. Before reporting a status change, at least two probe locations must agree; the third probe provides redundancy in case one location has a problem itself.
Health Check Analytics is now available to all Pro, Business, and Enterprise customers.
