# Configure Readiness and Liveness Probes API7 Gateway data plane (DP) nodes can expose built-in health endpoints on the status port, `7085` by default. You can use these endpoints in Kubernetes probes, load balancer health checks, or container-level checks to ensure traffic is sent only to healthy nodes. Use this guide when you need to: * configure Kubernetes readiness and liveness probes * add health checks in non-Helm Kubernetes manifests * configure Docker or external load balancer checks for non-Kubernetes deployments ## Health Check Endpoints[​](#health-check-endpoints "Direct link to Health Check Endpoints") When you configure the data plane `status` block, API7 Gateway provides health check endpoints on the status port (default `7085`). | Type | Path | Purpose | | ------------- | --------------- | ---------------------------------------------------------------------------------- | | **Liveness** | `/status` | Indicates if the process has successfully started and is running. | | **Readiness** | `/status/ready` | Checks worker synchronization and DP Manager availability for a connected gateway. | Use sync-aware readiness when you want to take a node out of rotation if it loses contact with DP Manager. When a node should serve cached configuration during an outage, check a published traffic port, or a path that still returns success from cached configuration. For nodes starting from fallback storage, see [fallback recovery](https://docs.api7.ai/api7-gateway/configure-and-manage/data-plane-resilience.md#recover-traffic-nodes-from-fallback-storage). The status endpoints are controlled by the data plane `status` configuration: config.yaml ``` apisix: status: ip: 0.0.0.0 port: 7085 ``` If you bind the status endpoint to `127.0.0.1`, local container checks still work, but external load balancers will not be able to reach it. ## Configure Probes in Kubernetes[​](#configure-probes-in-kubernetes "Direct link to Configure Probes in Kubernetes") ### Helm values[​](#helm-values "Direct link to Helm values") If you are deploying API7 Gateway via the `api7/gateway` Helm chart, enable the status endpoint and configure the probes in your `values.yaml` file. values.yaml ``` api7ee: status_endpoint: enabled: true ip: 0.0.0.0 port: 7085 gateway: livenessProbe: httpGet: path: /status port: 7085 initialDelaySeconds: 10 periodSeconds: 10 timeoutSeconds: 5 failureThreshold: 3 readinessProbe: httpGet: path: /status/ready port: 7085 initialDelaySeconds: 5 periodSeconds: 10 timeoutSeconds: 5 failureThreshold: 3 ``` The Helm chart exposes the underlying runtime `apisix.status` block through `api7ee.status_endpoint`, and the Kubernetes pod probes through `gateway.livenessProbe` and `gateway.readinessProbe`. This example uses `/status` for process liveness and `/status/ready` for sync-aware readiness. ### Non-Helm Kubernetes manifests[​](#non-helm-kubernetes-manifests "Direct link to Non-Helm Kubernetes manifests") If you deploy API7 Gateway with raw `Deployment` manifests instead of Helm, configure the probes directly on the gateway container: deployment.yaml ``` apiVersion: apps/v1 kind: Deployment metadata: name: api7-gateway spec: template: spec: containers: - name: gateway image: api7/api7-ee-3-gateway:3.10.9 ports: - containerPort: 9080 - containerPort: 9443 - containerPort: 7085 livenessProbe: httpGet: path: /status port: 7085 initialDelaySeconds: 10 periodSeconds: 10 timeoutSeconds: 5 failureThreshold: 3 readinessProbe: httpGet: path: /status/ready port: 7085 initialDelaySeconds: 5 periodSeconds: 10 timeoutSeconds: 5 failureThreshold: 3 ``` If you expose the gateway through a Kubernetes `Service`, do not send client traffic to port `7085`; keep it for health checks and operational access only. ## Configure Checks Outside Kubernetes[​](#configure-checks-outside-kubernetes "Direct link to Configure Checks Outside Kubernetes") ### Docker or container runtime checks[​](#docker-or-container-runtime-checks "Direct link to Docker or container runtime checks") For Docker deployments, publish the configured status port to the host and query the endpoints from there: ``` curl -i "http://127.0.0.1:7085/status" curl -i "http://127.0.0.1:7085/status/ready" ``` For a Docker Compose check inside the 3.10.9 gateway container, use the bundled `wget`: docker-compose.yaml ``` services: gateway: image: api7/api7-ee-3-gateway:3.10.9 volumes: - ./gateway_conf/config.yaml:/usr/local/apisix/conf/config.yaml:ro ports: - "9080:9080" - "9443:9443" - "7085:7085" healthcheck: test: ["CMD-SHELL", "wget -q -O- http://127.0.0.1:7085/status/ready >/dev/null 2>&1 || exit 1"] interval: 10s timeout: 5s retries: 3 start_period: 10s ``` This pattern is useful for local development, Docker Compose, or VM-based deployments where an orchestrator needs a simple container health signal. ### External load balancer checks[​](#external-load-balancer-checks "Direct link to External load balancer checks") For VM, bare-metal, or Docker deployments behind a load balancer, configure health checks against the DP status API: * use `http://:7085/status` when you only need to verify that the process is running * use `http://:7085/status/ready` when you want to stop routing traffic to nodes that have lost control plane connectivity When the load balancer should keep routing to nodes with cached configuration during an outage, check a published traffic port, or a path that still returns success from cached configuration. ## TCP Socket Checks[​](#tcp-socket-checks "Direct link to TCP Socket Checks") As an alternative to HTTP checks, you can use TCP socket checks on the proxy port (default `9080` for HTTP or `9443` for HTTPS). This is useful if you want to ensure the network stack is responding even if the status endpoint is unavailable. deployment.yaml ``` readinessProbe: tcpSocket: port: 9080 initialDelaySeconds: 5 periodSeconds: 10 ``` ## Expected Responses[​](#expected-responses "Direct link to Expected Responses") * **Success**: A `200 OK` response confirms that the specific check passed. * **Readiness failure**: A `503 Service Unavailable` response from `/status/ready` indicates that a worker is out of sync or that none of the configured DP Manager endpoints are available. Inspect the response body and gateway logs to distinguish the cause. * **Failure**: Any other status code, connection refusal, or timeout indicates a health check failure. ## Recommended Defaults[​](#recommended-defaults "Direct link to Recommended Defaults") * Use `/status` for liveness checks. * Use `/status/ready` where traffic eligibility depends on synchronization with DP Manager. * Keep the status port reachable only by your orchestrator, load balancer, or operations network. * If you run outside Kubernetes, make sure your `config.yaml` exposes the status port on an address your health checker can reach. ## Next Steps[​](#next-steps "Direct link to Next Steps") * [Data Plane High Availability](https://docs.api7.ai/api7-gateway/configure-and-manage/high-availability-data-plane.md) to design load balancer failover. * [Scale Data Plane](https://docs.api7.ai/api7-gateway/configure-and-manage/scale-data-plane.md) to add more traffic-serving nodes. * [Monitor Gateway Metrics](https://docs.api7.ai/api7-gateway/observability/metrics.md) to track health trends over time. * [Configure Centralized Logging](https://docs.api7.ai/api7-gateway/observability/logging.md) to debug probe failures.