Skip to main content
When an agent is live, silence is not the same as health. A process may still be running while its dependencies are failing, its task manager is stalled, or its readiness has quietly degraded. Without health and metrics endpoints, you are left inferring the state of the system from symptoms. Requests time out. Alerts arrive late. Small issues stay hidden until they become production incidents.

​
Why Health And Metrics Matter

An agent does not just need to be online. It needs to be ready, observable, and measurable while it works.
No health instrumentationBindu health and metrics
Hard to tell if the process is actually readyExplicit readiness and runtime state
Failures surface only through user-facing symptomsHealth endpoint exposes system condition early
Limited insight into request behaviorMetrics reveal traffic, latency, and task load
Harder to automate monitoringPrometheus-friendly output fits existing tooling
Debugging starts too lateVisibility begins from the first request
That is the shift: Bindu exposes simple operational signals so developers and platforms can understand whether an agent is alive, ready, and performing as expected.
If an agent is accepting requests but cannot actually process them safely, a plain process heartbeat is not enough. You need visibility into readiness, runtime dependencies, and traffic behavior.

​
How Health And Metrics Work

Bindu exposes two complementary views: 
/health  -> current runtime state
/metrics -> time-series operational signals
  • /health answers “is this agent ready right now?”
  • /metrics answers “how has this agent been behaving over time?”

Readable

Health responses expose runtime, application, and system state in one place.

Queryable

Metrics can be scraped by Prometheus-compatible systems for long-term monitoring.

Operational

Together they help teams detect readiness issues and performance drift early.

​
Health Endpoint

1

Check Health

The health endpoint answers the simplest operational question first: is the agent running and ready?
curl http://localhost:3773/health
Response fields:
FieldDescription
statusOverall health status (ok or degraded)
readyWhether agent is ready to accept requests
uptime_secondsTime since agent started
versionBindu version number
healthHealth status (healthy or degraded)
runtime.storage_backendStorage backend type (e.g., PostgresStorage)
runtime.scheduler_backendScheduler backend type (e.g., RedisScheduler)
runtime.task_manager_runningWhether task manager is running
runtime.strict_readyStrict readiness check status
application.penguin_idUnique agent instance identifier
application.agent_didAgent’s Decentralized Identifier
system.python_versionPython version
system.platformOperating system platform
system.environmentDeployment environment
2

Inspect Runtime State

The health response is not just a liveness check. It exposes enough context to tell whether the agent is actually safe to receive work.Readiness is often a dependency question. If storage, scheduling, or the task manager is degraded, the agent may be present but not truly ready.

​
Metrics Endpoint

The metrics endpoint exposes Prometheus-compatible time-series data so you can watch traffic, latency, concurrency, and active task load over time. 
curl http://localhost:3773/metrics
Available metrics:
MetricTypeDescription
http_requests_totalcounterTotal HTTP requests by method, endpoint, status
http_request_duration_secondshistogramRequest latency
agent_tasks_activegaugeCurrently active tasks
agent_tasks_completed_totalcounterTotal completed tasks by agent and status
http_response_size_bytessummaryResponse body size
http_requests_in_flightgaugeCurrent requests being processed

​
Real-World Use Cases

A deployment platform can call /health before routing traffic to the agent, making sure requests only hit instances that are actually ready.
curl http://localhost:3773/health
A monitoring stack can scrape /metrics continuously to track request counts, latency changes, and current task volume.
curl http://localhost:3773/metrics
If an agent appears live but behaves incorrectly, the health response can reveal which runtime pieces are active and whether strict readiness is being met.
{
  "runtime": {
    "storage_backend": "PostgresStorage",
    "scheduler_backend": "RedisScheduler",
    "task_manager_running": true,
    "strict_ready": true
  }
}

​
Best Practices

Monitor Readiness, Not Just Liveness

Use the full /health response to validate agent readiness instead of relying only on process existence.

Track Metrics Continuously

Scrape /metrics over time so latency, concurrency, and traffic issues are visible before they become outages.
Sunflower LogoWith Bindu, agent health is like a field of sunflowers — each one standing on its own, yet easy to observe and trust.