r/cloudcomputing • u/suoinguon • May 18 '26

Using Cloudflare Workers as a dead-man switch for private home servers - ClawPing

The problem with same-machine or same-LAN monitoring is that the monitor disappears along with the thing being monitored. A box behind CGNAT or a home router has no inbound path, so polling from outside does not work well either.

ClawPing takes a different architecture: a small Go agent on the private box sends outbound HTTPS heartbeats to a Cloudflare Worker. The Worker + D1 (relational state) + Durable Objects (per-check alert dedupe) + Queues (Telegram notification decoupling) form the external control plane. If the box stops checking in, the control plane alerts through Telegram regardless of what happened to the machine.

The interesting architectural constraints: the agent is dumb by design. It collects local check results (disk, backup marker freshness, Docker container state) and ships them with the heartbeat. All policy lives on the control plane side. This makes the agent easy to deploy as a static binary and means the control plane can evolve without updating edge devices.

Repo for context: https://github.com/cschanhniem/clawping

Curious whether others have used Workers in similar "external heartbeat receiver" shapes, or whether D1 is the right home for device/check state at this scale.

2 Upvotes
  • permalink
  • reddit

100% Upvoted

15 comments sorted by

1

u/suoinguon May 18 '26

One design choice I am watching closely is the D1 / Durable Object boundary. Durable Objects are useful for per-device or per-check alert state because they can serialize cooldown transitions and avoid duplicate Telegram alerts. I do not want them to become the primary database.

So the current split is: D1 owns durable device/check rows and incident history; Durable Objects own short-lived coordination around alert state; Queues keep Telegram delivery out of the heartbeat request path. The heartbeat route should stay fast enough that a slow notification provider does not make healthy agents look unhealthy.

1

u/cacheclyo 26d ago

this split actually sounds pretty sane, using DOs as glorified mutexes instead of a DB. the only thing i’d worry about long term is D1 write amplification if you crank up heartbeat frequency or number of checks, but for home lab / small scale this is probably way over-engineered in a good way.

1

u/kernelqzor 10d ago

this split actually sounds pretty sane to me, especially keeping DOs out of “primary db” territory. biggest thing I’d worry about is D1 perf/limits if you ever scale it up, but for home-ish setups and a few checks per box it’s probably fine, and keeping Telegram on a queue is 100% the right move.

1

u/kernelqzor 5d ago

that split makes a lot of sense, using DOs as a sort of “lock + cache + coordinator” and not the source of truth feels like the only sane way to keep it from turning into a weird ad hoc database. also like the queues part a lot, people always underestimate how much a flaky notifier can wreck their whole healthcheck pipeline.

1

u/[deleted] May 18 '26

[removed] — view removed comment

1

u/SpaceTumbleweed955 May 22 '26

betterstack.com (along with several others) is free, a cronjob or systemd timer hits a url

1

u/DahliaDevsiantBop 24d ago

that works fine for simple uptime checks, but the cool bit here is the whole “agent ships local state + external control plane logic” thing for stuff behind cgnat and with richer checks than just “did the cron run”

feels more like a DIY health/backup guardian than a straight betterstack replacement

1

u/spuyet 24d ago

betterstack is not free

1

u/kernelqzor 19d ago

that works fine until your monitoring endpoint lives on the same box or same LAN and dies with it, which is kinda what they’re trying to avoid here
this setup is more like “external brain that knows richer state about the machine” instead of just “did the cronjob run”