Self-host a UptimeRobot alternative on Cloudflare

Start with the production infrastructure sources

Open the UptimeFlare project page and its pinned source at a5670e51cbc167bf3610fce4d3389dd00141d729. The production setup is not fully described by a Wrangler file alone: deploy.tf defines the resources, and the deployment workflow builds and uploads them.

Resource	Source declaration	Pilot check
Scheduled Worker	uptimeflare_worker; one-minute Cron	Correct account, build and observed scheduled runs
D1	uptimeflare_d1, UPTIMEFLARE_D1 binding	State writes and reads in your own database
Status page	uptimeflare Pages project with D1 binding	Page and /api/data show the intended monitor state
Regional checker	REMOTE_CHECKER_DO, SQLite RemoteChecker migration	Required only for the chosen worker:// regional checks; verify routing

The pinned GitHub Actions workflow builds the Worker with Wrangler dry-run, builds Next.js through next-on-pages, initializes D1, runs the migration helper, applies Terraform and uploads Pages. Resource names are fixed in that source; isolate the account or review names before deploying alongside an existing installation.

Choose an account and protect monitor credentials

The workflow reads CLOUDFLARE_API_TOKEN and an optional explicit CLOUDFLARE_ACCOUNT_ID. It can infer the first returned account when the account ID is omitted. Set the intended account explicitly and review the upstream token permissions before running deployment. No credentials were supplied or upstream code executed for this guide.

Inspect uptime.config.ts: example authorization headers and notification URLs are placeholders, and sample maintenance dates are not your maintenance schedule. Replace the examples with a non-critical endpoint, deliberate status/keyword conditions and your chosen notification settings. Keep sensitive targets and credentials out of public repository history and review what build artifacts expose.

The README links an upstream security advisory about historical monitor-configuration exposure. Use a reviewed fixed revision and check subsequent advisories before deploying. Catalog source review does not replace an independent security assessment.

Run a failure and recovery pilot

1. Confirm the scheduled Worker and Pages use your intended D1 database.
2. Observe a healthy check and matching status-page data.
3. Use a controlled failing endpoint; verify the expected timeout, grace period and incident display.
4. Confirm a notification reaches an authorized destination and that a recovery message behaves as expected.
5. Inspect the public page and JSON API for private headers, targets and credentials.
6. Record scheduled CPU, Worker/Pages requests, D1 reads and writes, and any regional-checker usage.
7. Confirm who handles updates, backup, restore and monitoring of the monitor itself.

These are acceptance steps for your deployment, not tests completed by this article. A local preview is also insufficient evidence: the pinned development helper still references legacy KV while production uses D1.

Budget the real workload and keep a rollback path

Workers Free currently limits daily requests and per-invocation CPU; D1 separately limits daily reads, writes and storage. SQLite Durable Objects have request, duration and storage allowances. The shared account's other workloads count too. Start small and measure rather than asserting that the README's maximum monitor claim fits free hosting.

Existing UptimeFlare deployments need particular care: the pinned KV-to-D1 migration helper deletes the old KV namespace after successful migration. Back up the state and inspect the script before upgrading. This is separate from a UptimeRobot migration; historical data import from that service was not verified.

Keep existing monitoring during the pilot and consider an independent observation point for services hosted on Cloudflare. Use UptimeFlare vs UptimeRobot, pricing and the alternatives guide to decide whether taking on these operating tasks fits your team.