Menu

// use case: cloudflare workers

Monitor Cloudflare Workers uptime and crons

Workers fail in ways logs catch late: cold-route errors, origin timeouts, and scheduled handlers that silently stop. Ping both the routes and the schedules.

01

Probe worker routes from 6 regions

Point HTTP checks at your worker endpoints with keyword assertions on the response body, so a 200 with the wrong content still pages.

02

Heartbeat your scheduled handlers

Touch a ping token at the end of every scheduled() run with waitUntil, so a silently-skipped cron fires an alert instead of silence.

export default {
  async scheduled(event, env, ctx) {
    await doNightlyWork();
    ctx.waitUntil(fetch("https://ping.pinganywhere.com/cPAT_OK"));
  },
};

03

Correlate with the edge

Every ingestion carries x-pa-region and x-pa-latency headers, so you can tell a regional blip from a broken deploy at a glance.

PingAnywhere itself runs on Workers, so checks originate from the same kind of edge your code runs on.

We send one email when your region opens. Unsubscribe any time.

Frequently asked questions

How do I check a Cloudflare Worker is actually up?

Add an HTTP check on the worker route with a keyword assertion on the response body. A 200 carrying an error payload still pages you, which a plain status-code check would miss.

How do I monitor a scheduled() handler that never runs?

Ping a start token at the top of the handler and the success token at the end, both inside waitUntil. A skipped invocation means the success ping never arrives and you are alerted within one interval.

Does the agent inside Workers affect cold starts?

There is no agent. Reporting is a single fetch to a ping token, and checks are external probes, so your worker ships no monitoring code beyond one line.

Can I tell a regional outage from a broken deploy?

Yes. Every ingestion carries x-pa-region and x-pa-latency headers, so a single region failing is visible in the data instead of looking like your deploy broke.