Problem
There is no metrics endpoint and no error tracker. Combined with the current lack of structured logging (#96) and readiness checks (#97), there is no way to alert on error-rate spikes, latency regressions, or DB/IRMA failures — problems are only visible by reading container stdout after the fact.
Why it matters
- Metrics enable dashboards + alerting: request rate, latency, error rate, DB pool saturation.
- An error tracker captures stack traces + release context for unhandled exceptions, instead of losing them to stdout.
Proposal
Acceptance criteria
Related
Complements #96 (structured logging) and #97 (readiness probe).
Problem
There is no metrics endpoint and no error tracker. Combined with the current lack of structured logging (#96) and readiness checks (#97), there is no way to alert on error-rate spikes, latency regressions, or DB/IRMA failures — problems are only visible by reading container stdout after the fact.
Why it matters
Proposal
/metricsendpoint (prom-client) exposing default process metrics plus a few app series: HTTP request duration by route/status, session creations, API-key auths, IRMA calls. Restrict access (internal/allowlisted).handleErrorhook (builds on Observability: adopt structured logging with request correlation (replace ad-hoc console.*) #96) — Sentry or self-hosted GlitchTip — tagged with the release-please version.Acceptance criteria
/metricsserves Prometheus metrics including HTTP request duration + error counters./metricsaccess is restricted and documented.Related
Complements #96 (structured logging) and #97 (readiness probe).