Step 1: confirm an agent is assigned
In the console, open Metrics, then the metric in question. The detail page shows the assigned agent. If the field is empty, the metric is defined but no agent is collecting it. Set the Agent field and save. A running agent (1.6.0 or later) picks up the change within about 30 seconds, and pushes the metric’s first verdict as soon as it first evaluates it: you do not have to wait for a full report interval. Older agent versions check for new definitions every five minutes instead; restart such an agent, or upgrade it, to pull the updated list immediately.Step 2: confirm the agent is running
Open Agents in the console and verify the assigned agent shows status Running. Ready means the agent has never connected. If it shows Stopped, walk the stalled agent diagnosis.Step 3: confirm the probe is succeeding
If the metric reportsno_data rather than no value at all, the
agent ran the probe and the probe failed. The metric’s detail page
shows the latest reason string. New HTTP, TCP, DNS, TLS certificate,
ICMP, WebSocket and gRPC metrics show a failed probe as Unhealthy
by default (their no-data treatment), so check the reason on those
too.
Every code, grouped by source, is listed in
Reason codes.
The API returns the same information on
GET /metrics/{id} and
GET /metrics: reason is the stable code
to branch on, reason_label describes it in a few words, and
reason_hint says what usually causes it and how to fix it. agent_id
is the assigned agent, or null when there is none.
While a metric reports no_data, current_value is null: a failed
sample has no value. When the probe starts answering again,
pending_status shows the status the metric is changing to (for
example healthy) and pending_since when that was first seen. The
metric flips once its recovering confirmation time has passed.
For Prometheus probes, run the query directly against the
Prometheus server (the same URL the agent uses) and confirm it
returns a single scalar. For other probes, reproduce the request from
the agent’s host with the protocol’s own tool (curl,
openssl s_client, grpcurl, nc, ping, or the database client).
Step 4: confirm the threshold rule is correct
A metric stuck atdegraded typically has thresholds that leave a gap
the value sits in. Open the metric and verify:
healthy_operationandhealthy_valuedefine a band the value can reach.unhealthy_operationandunhealthy_valuedefine the failure band.- Comparison operators are strict (
overis>,underis<,equalis=). A value exactly on a boundary does not match that band.
Does no data count against an SLO?
It depends on the SLO’s unknown-data policy:
A metric can also turn no data into a status of its own with its
no data treatment (for example, count it as healthy for an
error-rate query that returns nothing).
Silent gaps count only for agents on version 1.4.0 or later and for
checks Observer runs itself. Older agents report only on change, so
upgrade them before relying on the
down policy.
Step 5: confirm the dashboard view
If the metric reports values in the console’s metric detail page but a status page shows no data, verify:- The metric is on the page (open the page builder).
- Private metric is off on the metric edit page. Private metrics are hidden from status pages.
Probe-specific guidesEach probe type has a dedicated configuration guide:
Prometheus,
HTTP,
TCP,
DNS,
TLS certificate.
Each one covers the probe-specific failure modes in detail. To
check a fix before you save it, test the check
once through its agent.

