Repository navigation
feat(ops): public health probes for uptime monitoring (v5.2.9) - #141
Merged
Merged
Conversation
A monitor pointed at /health gets 200 HTML from the SPA (Caddy routes
non-/api paths to nginx), so it reads as "up" even when the API or
database is down. Add proxy-reachable probes that actually reach the
backend:
- GET /api/v1/health — liveness ({"status":"ok"}).
- GET /api/v1/health/ready — readiness; runs SELECT 1 and a Redis ping,
returns {"status":"ready"} or 503 {"status":"degraded"}. It reports
only the overall state, never which dependency failed, so exposing it
leaks nothing. The internal /health/ready keeps its per-dependency
detail for the container healthcheck and same-host ops.
- nginx /healthz — a plain "ok" from the static site, so the frontend can
be monitored independently of the API.
Refactored the readiness logic into one _readiness() helper shared by the
internal and public probes. Added ops tests and a docs/deploy monitoring
section. Bump to v5.2.9.
pip-audit flagged 14 advisories against PyJWT 2.13.0 (the JWT library the auth tokens rely on); 2.15.0 clears them. Auth/security suites pass on the new version.
Transitive bumps only (vitest/undici chain); package.json unchanged, 237 frontend tests and the build pass.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds health endpoints a monitor can actually use.
/healthis answered by the SPA with200HTML (Caddy sends non-/apipaths to nginx), so a monitor there reads as "up" even when the API or DB is down. These reach the backend:GET /api/v1/health— liveness ({"status":"ok"}).GET /api/v1/health/ready— readiness:SELECT 1+ Redis ping →200 {"status":"ready"}or503 {"status":"degraded"}. Reports only the overall state (no dependency names, errors or versions), so it is safe to expose. The internal/health/readykeeps its per-dependency detail./healthz— plainokfrom the static site, to monitor the frontend independently of the API.Readiness logic refactored into one
_readiness()helper. Added ops tests and adocs/deploy.mdmonitoring section. Bump to v5.2.9.UptimeRobot after deploy:
…/api/v1/health/ready(keywordready) and…/healthz(keywordok).🤖 Generated with Claude Code