Built with Chinaski

Health Checks & Monitoring

Two unauthenticated health endpoints exist for monitors, plus an admin health dashboard in-app. This page explains what they report and how to wire them into monitoring.

GET /health — the full check

The instance’s own health endpoint isn’t just a ping — it runs a set of checks and reports the results individually:

  • Database reachability (critical) — the majority case for the endpoint’s “bad” answer.
  • Template-engine sanity (a quick compile of a test template).
  • Memory: the process RSS is read on Linux, compared against a 512 MiB threshold (informational warning when over).
  • Additional checks cover the build script/output environment; each check carries its own status, detail, severity (critical/warning/info), and measured latency.

The top-level answer reports status as critical if any critical check failed, warning if only warnings tripped, otherwise ok — plus a UTC timestamp, the number of checks, the per-check list, and a warnings array. An uptime monitor can read just the status field; an on-call engineer gets the check list instead.

GET /api/health — the site-level summary

Machine-monitor friendly: status (ok or a warning state if the site has content but never a build), published page count, last-built timestamp, and whether a build is in progress. Wire this one into external uptime checkers.

The cron build monitor

The repo ships a ready cron script (bin/cron-build-monitor.sh) designed to run every 5 minutes: it monitors that builds complete successfully and pages exist in the output tree (points at the instance’s output directory via the CHINASKI_OUTPUT environment). Schedule it from crontab as-is or use it as a template for your own monitor.

The production checklist’s ask

The README’s go-live checklist asks for exactly this wiring: monitor the health endpoint (/health reachable from your monitor; 503s when the database is unreachable), check backups run on schedule (systemctl list-timers chinaski-backup@<N> shows a NEXT), and keep an eye on journal-based logs after changes.