---
title: "Cloudflare uptime monitoring and health checks | Logdash"
description: "What Cloudflare Health Checks and Workers observability cover, which plan you need, the traps that fake an outage, and a Telegram alert in three steps."
url: https://logdash.io/monitor/cloudflare
---

# Cloudflare uptime monitoring

Cloudflare has no uptime check on the free plan; Health Checks start on Pro at $20 a month billed yearly and probe your origin directly, so to see what users see through Cloudflare you need an outside HTTP check on a health path Cloudflare never caches or challenges.

Cloudflare sits between your users and your server, which makes it the most important thing to monitor through and the worst thing to monitor with. When the origin dies, Cloudflare keeps answering with its own error pages: 521 when the web server refuses the connection, 522 when it times out, 523 when the origin is unreachable. Users see an outage. Nothing on the free plan tells you about it.

## Cloudflare health checks

Health Checks are Cloudflare's own monitor. None on Free, 10 on Pro, 50 on Business. Pro costs $20 a month billed yearly or $25 month to month, per zone. Each check probes an origin address over HTTP, HTTPS or TCP from the Cloudflare regions you pick, every 60 seconds by default, with retries and a consecutive-failure threshold, and notifies you by email or webhook. A standalone Health Check only watches. Moving traffic away from a dead origin is Load Balancing, a separate paid product.

The detail that matters: it probes the origin, not your public URL through the edge. A DNS record pointing at the wrong IP, a WAF rule blocking real users, or a cache rule serving yesterday's page all pass an origin check. And it runs on Cloudflare, so a Cloudflare outage silences the monitor along with the site.

## Cloudflare workers monitoring

Workers get requests, errors, CPU time and duration in the dashboard, plus Workers Logs once you set observability.enabled in the Wrangler config. Issues, in open beta since 30 September 2026, groups uncaught exceptions and 5xx responses and can route them to a webhook or a chat service. Edge and origin error-rate notifications are Enterprise only. All of these need failing traffic to fire. None of them ask whether the Worker answers right now, so give it a health route.

 src/index.ts 

```typescript
export interface Env {
  DB: D1Database;
}

const noStore = { 'cache-control': 'no-store' };

export default {
  async fetch(request, env): Promise<Response> {
    const { pathname } = new URL(request.url);

    if (pathname === '/health') {
      try {
        // One cheap query proves the D1 binding answers.
        await env.DB.prepare('select 1').first();
        return Response.json({ ok: true }, { headers: noStore });
      } catch {
        return Response.json({ ok: false }, { status: 503, headers: noStore });
      }
    }

    return new Response('Not found', { status: 404 });
  },
} satisfies ExportedHandler<Env>;
```

## Two traps that fake an outage

- Bot Fight Mode can answer a monitor with 403\. On the free plan it cannot be skipped by a WAF rule, so turn it off, or on Pro use Super Bot Fight Mode with a skip rule for /health.
- Caching. Cloudflare does not cache JSON by default, but a Cache Everything rule will, and then the check reads a stored 200 for hours. Send Cache-Control: no-store.

1. **Add the public URL** Create a service in Logdash and paste https://example.com/health, the hostname users hit, not the origin IP. Logdash sends a GET every 5 minutes on the free plan, every minute on Builder at $9 and every 15 seconds on Pro at $15.
2. **Connect Telegram** Add a Telegram channel once and attach it to the monitor. Any status outside 200-399, or no answer within 10 seconds, counts as down.
3. **Stop the origin** Stop the web server behind Cloudflare. The next check gets a 521 or 522 from the edge and a Telegram alert lands with the monitor name and that code, which tells you the origin is the problem, not Cloudflare.

### Logdash vs Cloudflare Health Checks

| Feature                    | Logdash                         | Cloudflare Health Checks        |
| -------------------------- | ------------------------------- | ------------------------------- |
| Free plan                  | 5 services, 5-minute checks     | Not available, Pro and up       |
| What it tests              | The public URL through the edge | The origin directly             |
| Check types                | HTTP checks                     | HTTP, HTTPS and TCP             |
| Check locations            | One location per check          | The Cloudflare regions you pick |
| During a Cloudflare outage | Runs outside Cloudflare         | Runs on Cloudflare              |

### When Cloudflare Health Checks is the better pick

- You already pay for Pro and want TCP checks on a database or mail port. Logdash only does HTTP.
- Several origins share one hostname and you need to know which one is sick. An outside check only sees the combined result.
- You use Cloudflare Load Balancing, whose monitors also steer traffic away from a dead origin. No outside monitor can do that.

### Does Cloudflare have an uptime check? 

Only on paid plans. Health Checks come with Pro (10 checks), Business (50) and Enterprise (1,000), and they probe your origin rather than the public URL. The free plan has no uptime check of any kind.

### Are Cloudflare health checks free? 

No. They need a zone on Pro or above, which is $20 a month billed yearly or $25 month to month. An outside monitor on its free plan covers the public URL instead.

### How do I set up Cloudflare website uptime monitoring? 

Add a health path that bypasses cache, make sure Bot Fight Mode does not challenge it, and point an outside HTTP monitor at the public hostname. A 521, 522 or 523 in the alert means the origin is down, not Cloudflare.

### What does Cloudflare Workers monitoring include? 

Requests, errors, CPU time and duration in the dashboard, Workers Logs when observability is enabled, and Issues in open beta for grouped exceptions. None of it checks that the Worker answers, so add a /health route and monitor it.

## Keep reading

[All platforms](https://logdash.io/monitor): One page per platform, each with what it already monitors, the gap, and a Telegram alert in three steps.

[Supabase monitoring](https://logdash.io/monitor/supabase): Supabase gives you usage reports, logs and a Prometheus metrics endpoint but no alert when your project stops answering, so deploy an edge function that runs select 1 against Postgres, returns 503 when it fails, and point an outside monitor at it.

[Coolify monitoring](https://logdash.io/monitor/coolify): Coolify watches its own servers and containers - reachability, container stops, disk usage, and CPU and memory through Sentinel - but it never requests your public URLs, so Coolify monitoring needs an outside check on each app and on the Coolify dashboard itself.

[Hetzner server monitoring](https://logdash.io/monitor/hetzner): Hetzner Cloud draws CPU, disk and network graphs for every server but sends no alert when one stops answering, so you add an outside HTTP check against a health path on the server or load balancer and route its alert to Telegram.

[Uptime monitoring](https://logdash.io/features/monitoring): HTTP checks as often as every 15 seconds. When one fails, Telegram tells you before your users do.