How to troubleshoot a down Prometheus target

A down Prometheus target means the scrape job is loaded, but the latest scrape did not return usable metrics. Troubleshooting the target quickly matters because up becomes 0, alert rules can fire, and dashboards that depend on that exporter stop receiving fresh samples.

Prometheus records scrape success in the up time series and stores the target address from the scrape configuration as the instance label by default. Start with the exact job and instance that are down, then test the same /metrics endpoint from the network path that Prometheus uses.

A Node Exporter target at 127.0.0.1:9100 keeps the endpoint and service names concrete. The same order applies to application exporters, blackbox exporter modules, or service-discovery targets by identifying the failing scrape, testing the scrape URL from the Prometheus host, restoring the endpoint or fixing the address, and waiting for the next scrape to report up as 1.

Steps to troubleshoot a down Prometheus target:

Query the failing target's up series.
```
$ promtool query instant http://127.0.0.1:9090 'up{job="node"}'
up{instance="127.0.0.1:9100", job="node"} => 0 @[1781952310.764]
```
Value 0 means Prometheus has the target, but the latest scrape failed. If the query returns no series, check whether the scrape job is loaded or whether the label selector matches the target.
Related: How to check Prometheus targets
Test the target metrics endpoint from the Prometheus host.
```
$ curl --silent --show-error http://127.0.0.1:9100/metrics
curl: (7) Failed to connect to 127.0.0.1 port 9100 after 0 ms: Could not connect to server
```
Use the same scheme, host, port, and /metrics path shown for the target in Prometheus. A workstation-only test can miss firewall, container-network, DNS, or bind-address problems on the Prometheus side.
Related: How to test a Prometheus metrics endpoint
Restart the exporter service that should answer the scrape.
```
$ sudo systemctl restart prometheus-node-exporter
```
Restart only the service that owns the failing endpoint. If the target points to the wrong host, port, scheme, or metrics path, fix the scrape configuration instead of restarting an unrelated exporter.

Related: How to manage the Prometheus service with systemctl
Related: How to add a Prometheus scrape config
Confirm that the metrics endpoint now returns Prometheus text output.
```
$ curl --silent --show-error http://127.0.0.1:9100/metrics
# HELP node_cpu_seconds_total Seconds the CPUs spent in each mode.
# TYPE node_cpu_seconds_total counter
node_cpu_seconds_total{cpu="0",mode="idle"} 400189.39
##### snipped #####
```
An HTTP 200 response with HELP, TYPE, and metric samples proves the exporter is listening. Authentication, TLS, or non-default paths must match the scrape job before Prometheus can mark the target up.
Wait one scrape interval and retest the original up query.
```
$ promtool query instant http://127.0.0.1:9090 'up{job="node"}'
up{instance="127.0.0.1:9100", job="node"} => 1 @[1781952318.85]
```
Value 1 means the latest scrape succeeded. If the endpoint works with curl but up stays 0, inspect the target details for timeout, HTTP status, TLS, authentication, or relabeling errors.