---
type: Article
title: "SNMP Voltage Monitoring"
description: "Sagging supply rails cause random reboots and corrupt writes long before anything crashes. Watch voltage over SNMP via a vendor MIB or a custom OID."
resource: "https://snmp-monitoring.com/sensors/environmental/voltage/"
tags: [sensors, snmp]
timestamp: 2026-07-13T00:00:00Z
---

# SNMP Voltage Monitoring

Voltage is the quietest sensor on the whole box and one of the most telling. When a supply rail starts sagging or a battery-backed line drifts out of tolerance, nothing crashes right away — but the odds of a random reboot, a corrupted write, or a dead component climb sharply. SNMP voltage monitoring lets you watch those rails and input feeds remotely and catch the drift before it turns into an outage. Here's the caveat to state plainly: voltage isn't a metric your server publishes by default. There's no universal OID for it, so to monitor voltage over SNMP you'll be working with a vendor MIB or a custom OID — and that's what this page is about.

## What is Voltage monitoring

Voltage monitoring means polling the electrical sensors on your hardware and, often, on the power equipment feeding it. Inside a server that usually means the motherboard's supply rails — the 3.3 V, 5 V, and 12 V lines, the CPU core voltage (VCore), memory and chipset voltages, plus a CMOS battery reading. Outside the server, PDUs and UPS units report input and output voltage for the whole rack or circuit.

Why watch it? Because every one of those rails has a tolerance band, and living outside that band is where trouble breeds. A 12 V line that sags under load hints at a struggling power supply or an overloaded circuit. A rail riding high stresses everything downstream of it. Ripple and instability — a value that won't sit still — can trigger the kind of intermittent, un-reproducible faults that eat days of debugging. On the input side, a dropping mains voltage is an early brownout signal, and a UPS reporting low battery voltage tells you how much runtime you actually have left when the grid blinks.

So the reading isn't just a number to confirm the lights are on. It's a health signal for the power chain. Monitor voltage over SNMP and you get a remote, continuous view of whether the electrical foundation under your workloads is steady — or slowly wandering somewhere it shouldn't be.

![Diagram: an external SNMP poller reading a server's supply-rail voltage OID over UDP from beyond the local network](https://snmp-monitoring.com/img/sensors/voltage-snmp-poll.webp)

## Why it's not in the standard host-resources MIB

The MIBs everyone reaches for first — the Host Resources MIB (RFC 2790) under `1.3.6.1.2.1.25.*`, MIB-II for interfaces — describe a device as a logical machine: processors, memory, storage, running software. Electrical characteristics like rail voltage are physical, analog properties of the hardware. They fall entirely outside what those standards set out to model, so walking the host-resources tree tells you nothing about volts.

The standards body did define a proper home for readings like this: the Entity Sensor MIB (RFC 3433). Its generic column `entPhySensorValue` at `1.3.6.1.2.1.99.1.1.1.4` can carry a voltage, with `entPhySensorType` distinguishing `voltsDC` from `voltsAC`. On gear that implements RFC 3433, that's the clean, portable place to poll. But implementation is patchy — a great many servers, PDUs, and UPS units never populate the entity-sensor tree and surface their electrical data through a vendor enterprise MIB instead.

Which puts voltage firmly among the **advanced sensors**: not gathered by default, absent from a generic scan, and tied to whatever object your particular hardware chose to use. No monitoring tool reads it for you automatically. You identify the exact object, allow it, and poll it on purpose. That's more deliberate than reading built-in metrics — but voltage is exactly the sort of slow, silent drift that rewards the effort of watching it.

## Finding the right vendor OID

Everything hinges on matching your hardware to its voltage object. The vendor's MIB is the source of truth — open the file in a MIB browser or with `snmptranslate`, and the voltage sensors are usually named clearly (rail labels, "input voltage," and so on). No MIB handy? Discovery by walking works, though voltage takes a little care, because agents frequently report the value scaled (millivolts, or a value you divide by ten or a hundred).

A sensible discovery routine:

- **Standard tree first.** `snmpwalk -v2c -c public <host> 1.3.6.1.2.1.99.1.1.1` — where RFC 3433 is present, voltages appear with `entPhySensorType` = `voltsDC` or `voltsAC`.
- **Then the vendor enterprise subtree** under `1.3.6.1.4.1.<vendor-number>`, hunting for values that map onto known rails once you apply the scale.
- **Always resolve the scale.** `entPhySensorScale` and `entPhySensorPrecision` (or the vendor's equivalents) tell you whether "3300" means 3.3 V. Getting this wrong makes every alert meaningless.

These are genuine, vendor-published MIBs — but the exact numeric OID and per-rail index depend on the model, so read them as pointers and confirm against the MIB shipped for your device. Don't paste a number you haven't verified.

| Platform / vendor | MIB to consult | Typical voltage object | Notes |
|---|---|---|---|
| Standards-based (many devices) | ENTITY-SENSOR-MIB (RFC 3433) | `entPhySensorValue` (`1.3.6.1.2.1.99.1.1.1.4`) | `entPhySensorType` = voltsDC / voltsAC; mind the scale |
| Linux + Net-SNMP host | LM-SENSORS-MIB | `lmVoltSensorsValue` | Exposes `lm-sensors` board voltages by index |
| Cisco | CISCO-ENTITY-SENSOR-MIB / CISCO-ENVMON-MIB | `entSensorValue` / voltage-state object | Rail voltage plus state on many platforms |
| APC / Schneider UPS-PDU | PowerNet-MIB | input/output voltage object | Line and battery voltage for UPS and rack PDUs |
| Dell servers | iDRAC / server MIB | voltage-probe object | Consult the iDRAC MIB bundle for the model |
| HPE servers | CPQHLTH-MIB | voltage-status object | HP Insight / iLO health MIB |

If the object won't reveal itself, don't invent one — a wrong OID charts a confident lie. The [custom OID guide](/sensors/custom-oid.md) covers discovery in more detail.

## Setting it up as a custom OID

Once the object is confirmed, setup is quick. The recurring gotchas are the agent not exposing the branch and a strict allowlist hiding it — plus, for voltage specifically, the scaling factor.

1. **Confirm by hand.** `snmpget -v2c -c public <host> <your-voltage-OID>` should return a value that maps to a known rail once scaled. A timeout is a reachability or community-string problem, not the OID.
2. **Expose it in the agent.** Adjust your [snmpd.conf](/setup/snmpd-conf.md) so the daemon serves the branch; on Linux, enable the `lm-sensors` extension for LM-SENSORS-MIB voltage objects to appear.
3. **Allow the OID.** Add a `view ... included` line for the exact object in your [OID allowlist](/setup/oid-allowlist.md) — a locked-down allowlist will hide the sensor until you name it.
4. **Register it as a custom OID.** With [custom OID monitoring](/sensors/custom-oid.md), add the object, label each rail, and set volts as the display unit.
5. **Bake in the scale.** Apply the divisor or `entPhySensorScale` factor in the poller so the chart reads 3.3 V rather than 3300. Check one rail against a known-good value before trusting the rest.

This is advanced configuration, sitting beside the other physical readings you'd wire the same way. The neighbours are listed in the [sensor & OID catalog](/sensors/index.md) and the flat [all sensors index](/sensors/all.md).

## Alerting

Voltage alerting is a tolerance-band problem, and the bands belong to the hardware — not to a number you'd guess. Each rail has a spec with acceptable upper and lower limits, and many vendor MIBs publish those thresholds, sometimes with a companion status object that flips to `warning` or `critical` on its own. Read them and alert off them. A round figure you invent will either cry wolf or miss the real event.

Some patterns deserve their own attention:

- **A rail trending toward the edge of tolerance** — early sign of a degrading power supply, worth a warning before it breaches.
- **Ripple or instability** — a value that jitters instead of holding steady often precedes intermittent, hard-to-repeat faults.
- **Input/mains voltage sagging** — a brownout signal; pair it with [power-supply status](/sensors/environmental/power-supply.md) to see the whole picture.

And this is where external polling earns its place. A power problem is precisely the scenario in which the on-box agent can't be trusted to warn you — if the rail collapses, so does the thing meant to send the alert. Polling from outside removes that dependency. It's the idea behind [double durability](/monitoring/double-durability.md): an independent watcher keeps reading your voltage OID even as the hardware falters. [ostr.io Monitoring](https://ostr.io/service/monitoring) polls the object from outside your network and fires real-time email and SMS alerts the moment a rail leaves tolerance, so an electrical fault reaches you even when the affected box can't send anything at all.

![Chart: 12V, 5V, and 3.3V supply rails over 24 hours with upper and lower tolerance-band lines drawn per rail](https://snmp-monitoring.com/img/sensors/voltage-rails-chart.webp)


## FAQ

**Is there a universal OID for voltage over SNMP?**
No. The standard object is `entPhySensorValue` at `1.3.6.1.2.1.99.1.1.1.4` in the Entity Sensor MIB (RFC 3433), with `entPhySensorType` marking `voltsDC` or `voltsAC` — but not every device implements it, and many expose voltage through a vendor MIB. Identify the object your specific hardware uses.

**Why isn't voltage in the host-resources MIB?**
The Host Resources MIB (RFC 2790) models logical resources — CPU, memory, storage. Voltage is a physical, analog property that lives in the Entity Sensor MIB or a vendor enterprise MIB and isn't collected by default.

**Why does my voltage reading look like a huge integer?**
It's almost certainly scaled — reported in millivolts or with an `entPhySensorScale` factor to keep it an integer. Apply the divisor the MIB specifies so "3300" becomes 3.3 V. Always confirm the scale before alerting.

**What thresholds should I set for a rail?**
Use the tolerance limits from the hardware spec or the vendor MIB, which are matched to that rail. Where a device exposes a voltage status object, alert on its state change rather than reinventing the band yourself.

**Can I monitor UPS and PDU voltage the same way?**
Yes. UPS and PDU input/output voltage is exposed by MIBs like PowerNet-MIB and handled with the same custom-OID approach. See also [power-supply monitoring](/sensors/environmental/power-supply.md).

## Conclusion

SNMP voltage monitoring rewards the setup effort because electrical drift is silent right up until it isn't. There's no default OID: rely on the standard `entPhySensorValue` (`1.3.6.1.2.1.99.1.1.1.4`) where RFC 3433 is implemented, or the correct vendor MIB object where it isn't, then expose it in [snmpd.conf](/setup/snmpd-conf.md), allow it, and register it as a [custom OID](/sensors/custom-oid.md) with the right scale. Alert against the hardware's tolerance bands, watch for ripple and input sag, and poll from outside so a power fault still reaches you when the affected machine can't speak for itself.