5563, the container port named http in the chart). The three Kubernetes probes report process state only. /health is the one endpoint meant for a monitor outside the cluster, and the only one that reports the control plane.
Endpoints
None of these endpoints requires a key. With the chart’s default ClusterIP Service and ingress,
/health is the only one published and the rest stay in-cluster. A Service of type LoadBalancer publishes all of them, /debug/control-plane included.
Probe responses
The three probes share one body:status is ok, draining or starting. version carries the ENVIRONMENT value. The gateway registers no dependency checks on the probes, so a checks map never appears: dependency state is on /health, in the per-request error codes and in the traces.
/healthz
probes.liveness.*. The handler does no network I/O.
/readyz
After SIGTERM the endpoint answers:
probes.readiness.*. SIGTERM is the only condition that flips it. Readiness does not check the control plane: warm virtual keys keep serving from the auth cache through a control plane outage, and dropping every pod from the load balancer would turn that degradation into an outage. It does not check providers or any shared store either; the gateway has no database and no shared cache.
/startupz
probes.startup.*. Startup is marked complete while the process builds its dependencies, before the listener opens, so the starting state is not observable over HTTP. The auth cache warms on the first request per virtual key; there is no bootstrap step to wait for.
/health
Point a status page or uptime monitor at https://<ingress.host>/health. GET and HEAD answer 200 when healthy and 503 when not; any other method answers 405. Every response carries Cache-Control: no-store.
/api/internal/gateway/health every 15 seconds over the same HMAC-signed channel every request uses, with a 5 second timeout. A success proves DNS, the connection, the app being up and LW_GATEWAY_INTERNAL_SECRET matching on both sides. A secret mismatch is the one misconfiguration where every probe is green and every virtual key resolve is refused, and this endpoint is what catches it.
The verdict flips to 503 after 60 seconds without a successful probe, and a new pod gets one full 60 second window before it can report 503, so a rolling deploy does not blink the page. The endpoint never contacts a model provider: a provider outage fails completions and leaves /health at 200. A poll reads the cached verdict and triggers no call.
The probe failure itself is logged on the gateway pod as statusprobe_control_plane_unreachable, with the underlying error.
enabled: false to keep the endpoint in-cluster.
Graceful shutdown
OnSIGTERM the gateway flips /readyz to 503, waits shutdown.preDrainWaitSeconds (default 5), closes the listener and gives in-flight requests shutdown.timeoutSeconds (default 60). terminationGracePeriodSeconds must cover both plus 10 seconds of slack. The sequence, the metrics to watch and the values for long streams are on Helm chart.
If requests still reach a pod after it flipped to draining during a rollout, raise shutdown.preDrainWaitSeconds and terminationGracePeriodSeconds together. A preStop sleep delays the SIGTERM instead, so the pod still reports ready during the sleep and the load balancer has no signal to act on.
Synthetic request
Neither the probes nor/health exercise the request path. Run a small completion on a schedule and alert on it internally, so a provider incident does not show on your public status page:
X-LangWatch-Gateway-Request-Id response header and search for it in Trace Explorer. A 502 provider_error with the provider’s message in the body means the gateway is healthy and the provider is not.
Common failures
More symptoms are on Troubleshooting.