> ## Documentation Index
> Fetch the complete documentation index at: https://docs.use.observer/llms.txt
> Use this file to discover all available pages before exploring further.

# Why metrics, not pings

> The case for metric-based status over availability pings.

Most status page tools assert availability with periodic pings: a
GET request every 60 seconds against a public endpoint, with a
green check when the response code is 2xx. Observer's default is
to compute status from metrics you already collect, with pings as
one source among many. The reasoning:

## Pings only see the public envelope

A ping confirms a single endpoint accepted a single request at a
single moment. It does not see:

* The error rate served to actual customers in the last five
  minutes.
* The 95th percentile latency under real load.
* The depth of an internal queue draining slower than its inflow.
* A degraded backend that has been masked by retries upstream.

A page driven only by pings can read green while customers see
errors.

## Metrics see the actual signal

Observer's primary data source is your own metrics: Prometheus
queries, HTTP probes that include body checks, TCP connection
times, DNS resolution times, TLS certificate expiry. The status
the public page shows is computed from the same numbers your
on-call team already trusts on the internal Grafana dashboard.

The result: when customers see red, the on-call's dashboard shows
the same red, with the same threshold semantics.

## Pings still have a place

For systems that do not emit metrics (third-party APIs, public
DNS, certificates issued by external CAs), the agent runs probes
directly. Observer also supports HTTP, TCP, DNS, ICMP, TLS
certificate, gRPC, WebSocket, database, OTLP, CloudWatch, Loki,
Elasticsearch, host metrics and custom probes. These produce a
metric in the same shape as a Prometheus query: a numeric value
with a timestamp, evaluated against thresholds.

> [!NOTE]
>
> **Use the right source per signal**
>
> * Internal API health: Prometheus query against your own metrics.
> * Third-party API reachability: HTTP probe.
> * Certificate expiry: TLS-cert probe.
> * DNS health: DNS probe.
>
> Mix as many as the system needs. Each becomes a metric on the
> status page with its own threshold band.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.