A container can be running while its application cannot serve a request. Before asking an OpenClaw agent to report container health, decide which signal you can observe: process state, Docker HEALTHCHECK, Kubernetes probe status, or a request from outside the workload. Each answers a different question. The Runbooks Container Health Monitor template sketches a check, but it is not a configured Docker or Kubernetes integration.
Translate the signal before writing an alert
| Observed signal | Useful interpretation | What remains unknown |
|---|---|---|
| Container running | The runtime has a live process | Whether the application responds correctly |
| Docker HEALTHCHECK unhealthy | The configured command failed enough times to meet its retry policy | Whether all user paths are broken |
| Kubernetes readiness failed | The pod should not receive normal service traffic | Whether a restart would help |
| Kubernetes liveness failed | The kubelet may restart the container under its restart policy | Whether users saw an outage |
| External request failed | That request failed from that vantage point | Whether every user or endpoint is affected |
Docker's HEALTHCHECK has an explicit command, interval, timeout, start period, and retry count. Its unhealthy state reflects that configured check, not a universal application verdict. Kubernetes uses readiness to decide when a pod can serve traffic and liveness to decide when to restart it. Treat a readiness failure during startup differently from a sustained failure after a healthy period; record the probe and deployment context rather than flattening both into 'container down'.
A small acceptance test for the Runbooks template
The current Container Health Monitor listing says 'Every 5 minutes' and suggests querying a Docker or Kubernetes API, then alerting on stopped containers, restart loops, and resource usage. Its declared skills are web_fetch and message. Those words do not grant cluster credentials, supply a secure network path, or register a five-minute Automation. Before adopting it, specify the exact read-only source, the permission boundary, the schedule, and the actual notification destination.
- Pick one service and record its expected replica count, owner, and existing platform alert. If no health probe exists, distinguish process state from service readiness in the report.
- Expose only the minimum health/status data to the checker. Do not give a recurring summarizer a production Docker socket or broad cluster-admin access merely to read status.
- Create an explicit OpenClaw Automation and inspect its run record. A line in a HEARTBEAT.md template is an instruction, not proof of a registered schedule.
- Test a known healthy sample, a failed probe, and an unavailable monitoring source. The third case must say 'observation unavailable', not 'service healthy'.
- Route critical, actionable incidents through the existing platform pager. Let the agent add context and a link to the source of truth; verify both execution and delivery before relying on the notification.
Keep two clocks in the record
For every finding, keep the source observation time and the agent check time. A successful agent run reading an old snapshot does not establish current health. Record the service, environment, probe or endpoint, observed state, last transition, data age, and the follow-up owner. If a deployment is in progress, explain whether the result comes from a pod becoming unready, a restart, or an external request. This is a reporting format to implement and test, not a claim that the gallery template already produces it.
Start with the Container Health Monitor template if you need a checklist, then wire it to your actual status source. The useful outcome is a report that names the failing observation and its limits. A reassuring green run with no verified source observation is not a health check.
Inspect the Container Health Monitor template