How Observer works
A high-level view of the agent, the cloud, and how they exchange data.
Observer has two parts:
- Observer Agent, a small process you run inside your network. It reads metrics from your existing observability stack (Prometheus, HTTP endpoints, TCP services, DNS, TLS certificates) and computes the status verdict locally.
- Observer Cloud, the control plane. It receives status pushes from agents, runs SLO evaluation, persists data, and renders status pages, dashboards, and the API.
What crosses the network#
Only the precomputed verdict crosses the boundary from your network to Observer Cloud. The push payload is:
{ "metric_id": "<uuid>", "value": <number>, "status": "<healthy|degraded|unhealthy>", "timestamp": "<ISO8601>" }Raw query strings (PromQL, HTTP request bodies, DNS resolver responses) do not leave the agent. The cloud has no path back into your network; it cannot pull from your Prometheus or hit your endpoints directly.
What runs where#
| Concern | Location |
|---|---|
| Metric collection | Agent, in your network |
| Status verdict | Agent, computed against the threshold rule |
| SLO evaluation | Cloud, against pushed status |
| Status page render | Cloud |
| Webhook delivery | Cloud |
| Audit log | Cloud |
| Public API | Cloud |
Operational implications#
- The agent must run in a network segment that can reach your metric sources. The cloud cannot reach them on your behalf.
- The agent's own health is reported back to the cloud through
heartbeats. The cloud surfaces a stalled agent as
agent.offline. - The agent is stateless with respect to historical data: lost agents do not lose history, because all status pushes are persisted in the cloud.
Was this page helpful?