Observability

VaultTerm exposes the standard signals an operator needs to run it: a Prometheus metrics endpoint, liveness and readiness probes for orchestration and load balancers, and structured logs. None of these expose secret material — they report on the health and behavior of the process, not its contents.

Metrics

Prometheus-format metrics are served at /metrics.

Variable	Default	Purpose
METRICS_ENABLED	true	Master switch for the metrics endpoint.
METRICS_TOKEN	(unset)	Bearer token required to scrape /metrics.

When METRICS_TOKEN is set, scrapers must present it as a bearer token:

curl -H "Authorization: Bearer $METRICS_TOKEN" https://your-host.example.com/metrics

Set a strong METRICS_TOKEN in production so the endpoint is not open to anonymous scraping. Point your Prometheus job at /metrics with the token configured as a bearer credential.

Liveness and readiness

Two probes report process health, with different semantics.

Liveness — /health

GET /health answers whether the process is up. It is tolerant of dependency hiccups and is meant for “is the process alive” checks — restart logic, not traffic gating.

Readiness — /readyz

GET /readyz answers whether the instance is ready to serve traffic. It returns a non-ready status (HTTP 503) until its dependencies are healthy. It checks:

• Database — Postgres is reachable.
• Redis — the cache is reachable.
• Schema — migrations have been applied.
• Master key — the key provider is initialized and the master key is loaded.

Use /readyz as the gate for load balancers and rolling deploys, so traffic only reaches an instance once its database, cache, schema, and key provider are all good. The master-key check ties readiness to Cryptography: an instance that cannot unseal its master key is never marked ready.

curl -i https://your-host.example.com/readyz

Logging

VaultTerm logs through Pino as structured JSON. The verbosity is controlled by LOG_LEVEL:

LOG_LEVEL=info

Accepted levels are trace, debug, info, warn, error, fatal, and silent. Structured output ships cleanly into log pipelines for searching and alerting. Logs are written to be safe to aggregate — they describe events and outcomes, not secret values.

Related pages

• Core and database configuration — the database and cache that /readyz depends on.
• admin console — operator console that summarizes runtime posture.
• Audit logs — the security trail, distinct from operational logs and metrics.