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?