/healthz (liveness) and /readyz (readiness) endpoints out of the box, with automatic dependency probing, catalog introspection, and runtime-aware behavior.
Quick Start
Health endpoints are enabled by default with zero configuration:Endpoints
/healthz --- Liveness Probe
Returns server info, runtime context, and uptime. No I/O, no dependency checks.
- HTTP 200 --- server process is alive
- HTTP 503 --- server is degraded
/readyz --- Readiness Probe
Runs all registered probes in parallel, returns aggregate status with catalog introspection.
- HTTP 200 --- all probes pass (
"status": "ready") - HTTP 503 --- at least one probe unhealthy (
"status": "not_ready")
The
probes field is included by default in development but omitted in production to avoid leaking infrastructure topology. Control this with includeDetails.Runtime Availability
| Runtime | /healthz | /readyz | Notes |
|---|---|---|---|
| Node.js / Bun / Deno | Yes | Yes | Full support |
| Edge / Cloudflare / Vercel | Yes | No | No persistent connections to probe |
| CLI (stdio) | Yes | No | No HTTP server |
| Browser | Yes | Yes | Full support |
Auto-Discovered Probes
FrontMCP automatically registers probes for infrastructure it knows about:- Session store --- pings Redis or Vercel KV when transport persistence is configured
- Remote MCP apps --- reads health status from the built-in
HealthCheckManager
redis + transport.persistence, the session-store probe appears automatically.
Custom Probes
Add your own dependency checks:HealthProbeResult:
Configuration
Kubernetes
Docker
Catalog Hash
ThetoolsHash in the /readyz response is a SHA-256 hash of sorted tool names. Use it to detect config drift across instances:
Disabling Health Endpoints
/healthz, /readyz, and the legacy /health alias entirely.
Related
Server Configuration
HTTP server options
Production Build
Production deployment guide
Redis Setup
Redis configuration
Observability
Tracing and monitoring