Skip to main content

ADR 0009: Public status page and hidden /q endpoints

  • Status: accepted
  • Date: 2026-11-07
  • Decision makers: the user, who asked for a public status page and for the raw health endpoints to be hidden

Context and problem statement​

Quarkus health and metrics lived under /q and were reachable through the public ingress. People outside the team needed a way to see whether the service was up. Raw health, metrics and OpenAPI endpoints should not be on the internet.

Decision drivers​

  • Give outsiders a useful signal without exposing internals.
  • Keep the kubelet and scrapers working.
  • No new service to run.

Considered options​

  • Leave /q public and add a page on top.
  • Remove /q from the ingress and build a status page into the frontend.
  • A separate hosted status product.

Decision outcome​

The frontend serves /status and GET /api/status. The pod probes each backing service's readiness over the cluster network, reduces the results to three states per component and discards probe URLs, codes and bodies. Results are cached for 20 seconds with one shared in-flight probe run. The ingress no longer routes /q. On the API host /q is sent to the frontend so it answers 404, because that host's catch-all would otherwise serve it from the LMS service.

Consequences​

  • Good: outsiders see component states only. After the change, /q/health, /q/metrics, /q/openapi and /q/swagger-ui returned 404 on both web hosts.
  • Bad: no status history is stored.
  • Bad: there is no explicit per-address rate limit on the status route. The cache and response headers bound the load.
  • Bad: rolling the frontend back past this change removes the status page.

Confirmation​

curl the /q paths on both hosts and expect 404. /api/status returns the component list.

Sources​

.agents/tasks/status-page/ingress.md, .agents/tasks/status-page/review.md, frontend/src/lib/status/status.ts, infra/oci-devops/deploy/ingress.yaml.