> ## 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. # Metric shows no data > Diagnose a metric that displays no current value or status in the console. 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](https://docs.use.observer/agent/guides/diagnose-stalled-agent.md). ## 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. | `reason` | Probable cause | | - | - | | `ECONNREFUSED` | The host resolved but refused the connection: the port is closed, the service is down, or a firewall rejects it. | | `ENOTFOUND` | DNS resolution failed. Check `PROMETHEUS_SERVER_URL` or the probe's target hostname. | | `ConnectionRefused` | Reported by older agents, shown as **Could not connect**. It covers both a refused port and a hostname that does not resolve: check the host, the port and DNS from the agent. Current agents report `ECONNREFUSED` or `ENOTFOUND` instead. | | `EHOSTUNREACH` | No network route from the agent to the target. Check routing, VPN and firewall rules. | | `ETIMEDOUT` | Target is reachable but did not respond within the configured timeout. | | `unexpected_status:401` / `unexpected_status:403` | Authentication or authorization failed against the probe target. | | `no_data_for_query` | The PromQL returned no series. The series name or label match probably does not exist. | Every code, grouped by source, is listed in [Reason codes](https://docs.use.observer/agent/reference/reason-codes.md). The API returns the same information on [`GET /metrics/{id}`](https://docs.use.observer/api/metrics/get-metrics-by-id) and [`GET /metrics`](https://docs.use.observer/api/metrics/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](https://docs.use.observer/docs/concepts/slos-and-error-budgets.md#unknown-data-policy): | Policy | No data and silent gaps | | - | - | | `down` (default) | Count as downtime | | `exclude` | Left out; coverage is shown instead | | `up` | Count as available | 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. > [!NOTE] > > **Probe-specific guides** > > Each probe type has a dedicated configuration guide: > [Prometheus](https://docs.use.observer/agent/guides/prometheus-source.md), > [HTTP](https://docs.use.observer/agent/guides/http-probes.md), > [TCP](https://docs.use.observer/agent/guides/tcp-probes.md), > [DNS](https://docs.use.observer/agent/guides/dns-probes.md), > [TLS certificate](https://docs.use.observer/agent/guides/tls-cert-probes.md). > Each one covers the probe-specific failure modes in detail. To > check a fix before you save it, [test the check](https://docs.use.observer/agent/guides/test-a-check.md) > once through its agent. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.