How do I build a public status page without exposing my database?

The useful part first: a public status page is genuinely worth having - users and integrators want to know if you are up. The trap is wiring that page directly to your production database to read live health, which puts your database one query away from the whole internet. The convenience becomes an attack surface.

Use a one-way bridge so the public page can never touch your data. A private job - a cron, inside your network - aggregates health and writes a small summary file (per-service up or down, plus rolling uptime) to object storage. The public page reads ONLY that file. It is a notice board out front that a staff member updates, versus handing visitors the keys to the server room.

# One-way flow - the browser can only ever see the summary file:
#
#   [private cron] --writes--> status.json (object storage) <--reads-- [public page]
#      (has DB access)                                          (no DB, no logger access)
#
# - The cron overwrites a tiny JSON on a schedule.
# - The public page (or an edge worker) renders that JSON server-side.
# - There is NO code path from the public page back to the database.

The summary file doubles as your history store. Keep a rolling 90 days of daily up/down inside it even if the underlying source data is pruned sooner (say after 30 days). The status file becomes the memory, so your public uptime history outlives the raw logs. TigZig runs exactly this at status.tigzig.com: browser to edge worker to the summary file, with no path back to the database or the logging service.

Where this sits in the bigger picture: https://www.tigzig.com/agents-faq/what-should-i-monitor-for-a-small-production-app. For the private alerting that reaches you (versus this public page that informs users): https://www.tigzig.com/agents-faq/how-do-i-get-alerted-when-my-website-or-api-goes-down. Full item: https://www.tigzig.com/security/monitoring.