Problem

OpenClaw exposes /health and /healthz endpoints, but these only indicate that the gateway process is alive. They do not reflect whether the system is actually ready to process messages -- i.e., whether channel providers are connected, model providers are reachable, and the memory database is open.

This distinction matters for:

• Docker/Kubernetes deployments: liveness vs readiness probes are fundamentally different concepts. Using /health for both means containers are marked "ready" before channels are connected, leading to dropped messages during startup.
• LaunchAgent/systemd monitoring: Knowing the process is alive is not the same as knowing it can serve requests. A gateway with a crashed Discord provider but a live HTTP listener reports healthy but silently drops all Discord messages.
• Automated update pipelines: After openclaw update, a post-update script needs to verify the gateway is fully operational, not just that it started without crashing.

Proposal

Add a GET /ready endpoint that returns:

{
  "ready": true,
  "channels": {
    "discord": { "connected": true, "latencyMs": 45 },
    "telegram": { "connected": true, "latencyMs": 120 }
  },
  "memory": {
    "open": true,
    "chunks": 1247
  },
  "uptime": 3600
}

When any critical subsystem is not ready, return HTTP 503 with "ready": false and the failing component.

Design considerations

• Auth: Should require the same auth as other gateway RPC endpoints (not unauthenticated like /healthz).
• Lightweight: Must not trigger expensive operations (no embedding calls, no LLM probes). Just check connection state and database handle validity.
• Extensible: Plugins/extensions should be able to register their own readiness checks.

Use cases

1. Kubernetes: readinessProbe: httpGet: path: /ready ensures pods only receive traffic when fully initialized.
2. Post-update verification: curl -f http://localhost:PORT/ready in update scripts to confirm successful restart.
3. Monitoring dashboards: Display per-subsystem health status (memory DB, Discord connection, Telegram polling, etc.).
4. Multi-agent setups: Orchestrator can check if a specific agent's gateway is ready before routing tasks.

References

• [Bug]: /health and /healthz can return Control UI HTML 200 instead of machine health payload #18446 (/healthz returns incorrect content type)
• Docker deployment discussions in community Discord