I run two CyberPower PS1500AVRLCD UPS units in my homelab, both monitored through Network UPS Tools (NUT). A custom Python exporter scrapes the UPS data and exposes it for Prometheus, which feeds into Grafana. The dashboard is community dashboard 14104 - a popular NUT Status board built against the schema from the HON95/prometheus-nut-exporter project.

After setting this up, about a third of the panels showed “No data.” My first assumption was misconfiguration somewhere in the stack.

The problem

The affected panels covered input frequency, output current, input voltage min/max, transfer voltages, and temperature. Panels for the things that actually matter - battery charge, runtime, status, load, input and output voltage - looked correct.

“No data” in Grafana usually means one of three things: the metric does not exist in Prometheus, the labels do not match the panel query, or the datasource configuration is wrong. I went through each.

Investigation

I verified the stack from top to bottom.

Prometheus scraping was healthy. The nut-server job was scraping from nut.internal:9995 successfully, with no errors on the targets page and up{job="nut-server"} returning 1 for both UPS devices.

The core metrics were present. Querying {__name__=~"nut_.*"} returned everything expected for basic UPS monitoring: nut_status, nut_battery_charge, nut_battery_runtime_seconds, nut_input_voltage_volts, nut_output_voltage_volts, nut_load. Both devices reported with the correct ups labels.

The exporter itself was working as designed. It only emits a metric when the UPS actually provides a value for that field - if the UPS returns nothing, the field is skipped and no time series is created. I curled the exporter endpoint directly and compared its output against what the missing panels were querying.

That is where the investigation ended. The panels showing “No data” were querying metrics the exporter was not producing because the UPS hardware was not reporting those NUT variables at all:

• nut_input_frequency_hertz - device does not report input.frequency
• nut_output_current_amperes - device does not report output.current
• nut_input_voltage_maximum_volts / nut_input_voltage_minimum_volts - no min/max voltage tracking
• nut_input_transfer_high_volts / nut_input_transfer_low_volts - no transfer voltage reporting
• nut_output_frequency_hertz - no output frequency
• nut_temperature - no temperature sensor

The CyberPower PS1500AVRLCD is a consumer-grade line-interactive unit, not a rack UPS with full telemetry. Dashboard 14104 was built expecting a broader hardware profile. You can verify what your UPS actually reports by running upsc <upsname> on the NUT server - anything not in that output will never appear in Prometheus.

The fix

While reviewing the skipped fields, I found two NUT variables the hardware does provide but were missing from the exporter’s supported fields list:

• input.voltage.nominal - 120V nominal input voltage
• ups.realpower.nominal - 900W nominal real power

I added both to the exporter’s configuration, mapping them to:

• nut_input_voltage_nominal_volts
• nut_realpower_nominal_watts

After redeploying the script, those two panels filled in correctly for both devices:

nut_input_voltage_nominal_volts{ups="ups_1@localhost"} 120.0
nut_realpower_nominal_watts{ups="ups_1@localhost"} 900.0

What stays empty

The rest of the blank panels - frequency, current, temperature, transfer voltages - stay empty. The hardware does not measure those things. This is expected with consumer-grade UPS devices on a dashboard built for a wider hardware range. The core monitoring is all there: status, battery charge, runtime, load, voltage. That covers everything I need for alerts.

What I learned

“No data” in Grafana is a symptom, not a diagnosis. It can mean the metric does not exist, the labels are wrong, the datasource is misconfigured, or - as here - the hardware simply does not measure that thing. Following the stack down (Grafana query → Prometheus → exporter → device) is faster than assuming any single layer is broken.

Community dashboards cover a superset of what any specific device will report. Before debugging, run upsc <upsname> on the NUT server and compare its output against the dashboard’s metric names. That comparison tells you immediately which panels will ever have data and which will not.

An exporter that skips fields with no data is doing the right thing. Emitting zero for a sensor the hardware does not have would produce misleading data in alerting rules - zero load and zero temperature look like real readings. Empty panels are more honest than fabricated metrics.