Cloudflare Workers and Pages are remarkably reliable. The edge network spans 300+ data centers, deploys are global in seconds, and the platform handles scaling automatically. But "remarkably reliable" is not "infallible." Workers hit CPU limits, D1 bindings fail silently after schema changes, Pages builds deploy broken SSR code while static assets work fine, and the Cloudflare dashboard shows green while your users see errors.

If you are building on Cloudflare -- and especially if your business depends on it -- you need external monitoring that checks your application from outside Cloudflare's network. CronAlert itself runs on Cloudflare Workers and Pages, so we monitor ourselves with external checks. This is the guide we wish existed when we set it up.

What can go wrong on Cloudflare

Understanding the failure modes helps you set up the right monitors. Here are the ways Cloudflare Workers and Pages actually break in production:

Worker errors

  • CPU time exceeded (1101). Workers have a CPU time limit -- 10ms on the free plan, 50ms on the paid plan (with up to 30 seconds of wall-clock time for async I/O). If your code does too much computation in a single request, Cloudflare kills it. This is the most common Worker failure mode.
  • Memory limit exceeded (1102). Workers have a 128MB memory limit. Processing large files, building up large arrays, or leaking memory across requests can hit this. The Worker terminates immediately with no graceful shutdown.
  • Unhandled exceptions. A bug in your code that throws an uncaught error returns a generic 500 error to the user. Cloudflare logs it in Workers Analytics, but does not alert you.
  • Binding failures. Your Worker deploys, but a KV namespace, D1 database, R2 bucket, or Service Binding is misconfigured or unreachable. The Worker itself starts fine -- it crashes only when it tries to use the broken binding.

Pages failures

  • Build failures that partially deploy. A Pages build can fail in a way that deploys static assets but breaks server-side rendering. Your marketing pages load fine, but your app pages (which use SSR) return errors. This is especially common with Astro, Next.js, and other frameworks that mix static and dynamic pages.
  • Function routing errors. Pages Functions (the Workers layer behind Pages) can have routing mismatches where the URL pattern does not match the file structure in functions/. Requests that should hit your server-side code fall through to a 404.
  • Environment variable changes. Updating an environment variable in the Pages dashboard does not redeploy your site. The new value only takes effect on the next deployment. If you change a database URL or API key and forget to redeploy, your site keeps running with the old value until the next push.

Platform-level issues

  • Regional outages. Cloudflare's edge network is distributed, but individual data centers or regions can have issues. A degradation in a specific region affects users routed through that data center while the rest of the world works fine. The Cloudflare status page often takes 10-15 minutes to update -- external monitoring catches it faster.
  • D1 issues. D1 is still a relatively new product. Occasional latency spikes, replication delays, or availability issues can affect Workers that depend on it. If your Worker's health depends on D1, you need to monitor that dependency explicitly.

Setting up monitors for Cloudflare Workers

Basic HTTP monitoring

The simplest setup: create a CronAlert monitor pointing at your Worker's URL. This catches any response that is not a 200 -- CPU limit errors, memory limit errors, unhandled exceptions, and binding failures all return non-200 status codes.

  1. Sign up for CronAlert (free plan works for this).
  2. Create a new monitor with your Worker URL, e.g., https://api.yourdomain.com/.
  3. Set the expected status code to 200.
  4. Set the timeout to 30 seconds (Workers can take time on cold starts with many bindings).
  5. Configure your preferred alert channels.

For Workers that serve an API, monitor a real endpoint rather than a synthetic health check. If your Worker powers /api/users, /api/products, and /api/orders, set up monitors for each critical path. A Worker can partially fail -- one route might work while another throws an error because it uses a different binding.

Health endpoint with dependency checks

For Workers with multiple bindings (D1, KV, R2, Durable Objects), add a health endpoint that verifies each one: 

export default {
  async fetch(request, env) {
    const url = new URL(request.url);

    if (url.pathname === '/healthz') {
      const checks = {};

      // Check D1
      try {
        await env.DB.prepare('SELECT 1').first();
        checks.d1 = { status: 'healthy' };
      } catch (e) {
        checks.d1 = { status: 'unhealthy', error: e.message };
      }

      // Check KV
      try {
        await env.KV.get('__health_check');
        checks.kv = { status: 'healthy' };
      } catch (e) {
        checks.kv = { status: 'unhealthy', error: e.message };
      }

      // Check R2
      try {
        await env.BUCKET.head('__health_check');
        checks.r2 = { status: 'healthy' };
      } catch (e) {
        // R2 returns an error for missing keys, which is fine
        checks.r2 = { status: 'healthy' };
      }

      const allHealthy = Object.values(checks).every(
        (c) => c.status === 'healthy'
      );

      return Response.json(
        { status: allHealthy ? 'healthy' : 'unhealthy', checks },
        { status: allHealthy ? 200 : 503 }
      );
    }

    return handleRequest(request, env);
  },
};

Monitor this endpoint with CronAlert and add keyword monitoring (Pro plan) to check that the response contains "healthy". This catches soft failures where the HTTP status is 200 but an individual binding has failed. See the database health endpoint guide for more patterns.

Monitoring Cloudflare Pages

Static pages vs SSR pages

Cloudflare Pages sites often mix static and server-rendered content. They fail independently and need separate monitors:

  • Static pages (marketing site, docs, blog) are served from Cloudflare's CDN and almost never go down. A single monitor on your homepage is usually sufficient -- if the CDN is serving static files, it is working.
  • SSR pages (app dashboard, API routes, authenticated pages) run Workers code. They depend on database bindings, environment variables, and server-side logic. These can fail independently of static content. Monitor each critical SSR route separately.

For a typical SaaS on Cloudflare Pages, set up these monitors:

URL Type What it catches
yourdomain.com Static CDN/DNS issues, total platform outage
yourdomain.com/app/dashboard SSR Worker errors, binding failures, auth issues
yourdomain.com/api/healthz API D1/KV failures, code bugs, CPU limits

Monitoring after deployments

Pages deploys are fast -- typically 30-60 seconds from push to global availability. But that speed means a broken deploy reaches production before you have time to check it manually. Combine external monitoring with your CI/CD pipeline to catch deploy-time failures:

  1. Push code to your git repo.
  2. Cloudflare Pages builds and deploys automatically.
  3. CronAlert checks your endpoints every 1-3 minutes.
  4. If the deploy broke something, you get an alert within minutes.

For faster detection, add a post-deploy health check to your CI pipeline that hits your health endpoint immediately after the deployment completes. This catches issues in seconds rather than waiting for the next scheduled check.

Monitoring Cloudflare Cron Triggers

If your Worker uses Cron Triggers for scheduled tasks -- processing queues, sending reports, cleaning up data -- you need heartbeat monitoring. Cron Triggers can fail silently: the trigger might not fire (misconfigured schedule), the Worker might crash during execution, or the Worker might exceed its CPU time limit partway through. 

export default {
  async scheduled(event, env) {
    try {
      await processScheduledTask(env);

      // Signal success to CronAlert heartbeat
      await fetch('https://cronalert.com/api/heartbeat/YOUR_MONITOR_ID');
    } catch (err) {
      // Log the error -- heartbeat will NOT fire,
      // so CronAlert alerts you about the missed beat
      console.error('Cron job failed:', err);
    }
  },
};

Set the heartbeat monitor's expected interval to slightly longer than your cron schedule. If your cron runs every 5 minutes, set the expected interval to 6-7 minutes. This gives the function enough time to complete while still catching missed executions quickly.

Multi-region monitoring for edge applications

One of Cloudflare's biggest advantages is global distribution -- your Worker runs in the data center closest to each user. But this also means a problem in one region is invisible to users (and monitors) in other regions.

CronAlert's multi-region monitoring (Team plan) checks your Worker from 5 geographic regions simultaneously. If your Worker is healthy in the US but returning errors in Asia-Pacific, you will see the regional failure immediately. This is especially valuable for Workers that access region-specific resources or have different behavior based on request.cf.colo.

For Workers that do not need multi-region granularity, a single-region monitor is still valuable. Because Cloudflare routes your request to the nearest edge, even a single monitor exercises the full edge network path. The key is monitoring from outside Cloudflare -- not from another Worker or a Cloudflare-hosted check.

What to check: a monitoring checklist

Here is what to monitor for a production Cloudflare deployment:

  • Each critical Worker route. Not just one URL per Worker -- monitor each important path separately, especially if they use different bindings.
  • Health endpoint with binding checks. A /healthz that verifies D1, KV, R2, and any other bindings your Worker depends on.
  • Pages SSR routes. Static pages rarely break; SSR pages break in all the ways Workers break. Monitor them independently.
  • Cron Triggers. Use heartbeat monitors for every scheduled Worker function.
  • Custom domains. If you use a custom domain with Cloudflare, monitor the custom domain URL (not the *.workers.dev or *.pages.dev URL). DNS and SSL issues with custom domains are a common failure mode that default URLs bypass.
  • SSL certificates. CronAlert automatically checks for SSL certificate errors during every HTTP check. This catches certificate expiration, misconfiguration, and certificate authority issues on your custom domains.

Frequently asked questions

Does Cloudflare monitor Workers automatically?

Cloudflare provides basic analytics (request count, error rate, CPU time) in the dashboard, but it does not proactively alert you when a Worker starts returning errors or exceeds its CPU time limit. You need external monitoring to get notified when something breaks. Cloudflare's analytics tell you what happened after the fact; external monitoring tells you when it happens.

Can I monitor a Cloudflare Worker from outside Cloudflare's network?

Yes, and you should. CronAlert checks your Worker URL from multiple geographic regions outside of Cloudflare's infrastructure. This tests the full request path including DNS, Cloudflare's edge network, and your Worker code. Monitoring from inside Cloudflare would miss DNS issues, edge routing problems, and network-level failures.

How do I monitor Cloudflare Pages server-side rendering?

Monitor the URLs that use server-side rendering, not just the static pages. SSR pages run Workers code behind the scenes, and they can fail independently of static assets. Set up separate monitors for static pages (which should basically never go down) and SSR pages (which depend on Workers, D1, KV, and other bindings). Use keyword monitoring to verify the response body contains expected content, not just a 200 status.

What Cloudflare Worker errors should I watch for?

The most common Worker errors are: 1101 (Worker exceeded CPU time limit), 1102 (Worker exceeded memory limit), 1015 (rate limited), and generic 500 errors from unhandled exceptions. A standard HTTP status code check catches all of these since they return non-200 status codes. For more subtle issues like incorrect response bodies, add keyword monitoring to verify the content.

Start monitoring your Cloudflare stack

Cloudflare is a great platform, but no platform monitors itself for you. Workers hit CPU limits, Pages deploys break SSR, D1 bindings go stale, and Cron Triggers fail silently. External monitoring from outside Cloudflare's network is the only way to see your application the way your users see it.

Create a free CronAlert account and set up monitors for your Workers, Pages routes, and Cron Triggers. The free plan gives you 25 monitors with 3-minute checks -- more than enough to cover a typical Cloudflare deployment. Upgrade to Pro ($5/month) for 1-minute checks and keyword monitoring, or Team ($20/month) for multi-region checks across 5 geographic regions. See the pricing page for full plan details.