Almost Reinventing Uptime Kuma, Badly

A status widget for the About page needs somewhere to get uptime history from, and the first design reached for what was already at hand: a scheduled GitHub Action pinging the site every few minutes and writing pass/fail rows to a new Postgres table. It would have worked. It also would have been a worse, unmaintained clone of a tool that already does exactly this, correctly, with a public status-page API included.

What the reinvention was missing

Uptime Kuma has been on this site's own listed skills the whole time, unused — true of the monitoring stack in general, since Prometheus and Grafana are real professional experience that this personal project had never actually run. Building a bespoke heartbeat table would have shipped a widget while quietly making the skills list less true, not more.

What using the real tool cost instead

Deploying Uptime Kuma meant new infrastructure on a production host — a container, reachable only over the internal Docker network, no public router, admin credentials generated once through a tunneled browser session and never exposed. That's a heavier lift than a GitHub Action, but it's a real deployment of a real tool instead of a demo of one, and the site's own public health endpoint becomes the thing Kuma polls end-to-end, through Cloudflare and Traefik, exactly as a real visitor would hit it.

The actual trade-off

A DIY heartbeat table would have been faster to ship and looked identical from the outside. The difference only shows up in what it's evidence of: one version proves the ability to write a cron job and a database table, the other proves the ability to run the monitoring stack this site's own bio claims to know. For a page whose entire purpose is showing real, live proof of a claim, the slower option was the only one actually doing its job.