Skip to main content
A metric with no recent value is almost always one of three problems: no agent is assigned to the metric, the assigned agent is not running, or the agent is running but the probe itself returns an error.

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 reports no_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 at degraded typically has thresholds that leave a gap the value sits in. Open the metric and verify:
  • healthy_operation and healthy_value define a band the value can reach.
  • unhealthy_operation and unhealthy_value define the failure band.
  • Comparison operators are strict (over is >, under is <, equal is =). 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.