Running a 120-site uptime monitor for $0/month on Cloudflare's free tier

Christian — Sat, 11 Jul 2026 06:33:02 +0000

I built a tool that answers one question: when a website won't load, is it your connection or the site? It runs two checks in parallel — measures your own line in the browser (latency + a 1 MiB download), and probes the target from Cloudflare's edge — then returns one of four verdicts: it's not you, it's you, it's both, or all clear. Demo: https://itsnotyou.site

The interesting part isn't the tool, it's that the whole thing — app, ~120 monitored sites with 24h history, SSR status pages, share cards, outage alerts — runs for $0/month plus domains.

The one thing that wanted to cost money

Everything fit the Workers free plan except a background monitor probing ~120 sites on a tight cadence. As a Worker cron that's ~120 subrequests/run and, done naively, thousands of KV writes/day — which pushes you onto Workers Paid. The real ceiling is KV: 1,000 writes/day.

So I split it. The user-facing test stays on Cloudflare — the edge probe still measures from the colo nearest the user, which is the point of edge. But the background sweep moved to a cheap VPS I already had: it probes the roster on a systemd timer and pushes results back into KV over the REST API.

Staying under 1,000 KV writes/day

One KV key, not key-per-site. All ~120 statuses live in a single blob. Key-per-site at sweep cadence would be millions of writes/month; a single blob is one write per sweep.
Widen the cadence. I started at 2 min = 720 writes/day. Cloudflare emailed that I'd hit 50% of the daily limit (the sweep wasn't the only writer). I went to 3 min = 480/day, leaving headroom for share cards and the notify list.
Move the hot counter off KV. The anonymous "tests today" counter was the sneaky risk — a traffic spike could exhaust the write budget and stall the status sweep, the one thing you can't let happen. It went to Analytics Engine instead (free, uncapped, separate budget). Now no amount of user traffic can starve the monitor.

Reader and writer share code so their rules never drift: the streak/history folding and the up/slow/down decision are pure modules that run under both the Workers runtime and Node on the VPS. Keeping them free of Worker-only and Node-only APIs was a mild constraint that paid off — a public status word can never disagree with what the sweeper wrote.

Other free-tier tricks

Single Worker + static assets, not Pages + two Workers. Anything matching a file in ./public is served statically and never wakes the Worker.
Rate limiting is in-memory per colo (a speed bump — KV-backed limiting costs a write per request). The real wall is one free zone Rate Limiting rule on /api/*.
The one cron I kept is cheap: a 5-min outage watch that reads the blob and pings Telegram when >20% of the roster is down (with hysteresis). 1 KV read + 1 fetch per tick.
Status pages are SSR and edge-cached, so search traffic mostly never reaches the Worker.

The SSRF footgun

A "type any URL and we'll fetch it from our edge" endpoint is an SSRF invitation. The probe does strict hostname validation, allows https:443 only, follows at most two redirects and re-validates at every hop (a redirect to http://169.254.169.254/ is the classic move), and caps at an 8s timeout.

Honest tradeoffs

The VPS is a real dependency. "$0 on Cloudflare" is true, but the sweep runs on a box I pay for elsewhere (spare capacity, so marginal cost was zero — YMMV). A cold-standby second box exists; the one rule is never run both sweepers at once or you double the writes.
Free-tier KV writes are a budget you actively manage. The 50%-usage email was a useful warning; otherwise I'd have found out via the sweep silently failing to push.

Stack: a Cloudflare Worker (no framework), vanilla single-file HTML/CSS/JS, KV for the status blob, Analytics Engine for counters, a Node script on a VPS on a systemd timer. Happy to go deeper.

Demo: https://itsnotyou.site

DEV Community: Christian

Running a 120-site uptime monitor for $0/month on Cloudflare's free tier