By the SNMP Monitoring team · Reviewed July 2026
Here's the failure mode that catches teams out: a server has two power supplies for redundancy, one dies, and absolutely nothing happens. No outage, no reboot, no alert — the second PSU quietly carries the whole load. The box is now running on a single point of failure and nobody knows. Weeks later the surviving supply fails, or a feed drops, and the server goes dark in a way that looks sudden but wasn't. SNMP closes that gap: it can report a PSU as failed or absent the moment it happens, while the system is still up, so you replace it before the redundancy is gone for real.
This is the how-to, focused on PSU presence, status and redundancy. Electrical values (voltage, current, power) have a reference twin at power sensor OIDs. Parent: hardware monitoring.
What SNMP exposes about PSUs
Two different kinds of data, and they come from different places:
- Presence — is a PSU installed in the bay at all?
- Status — is it OK, failed, or predicted to fail? (An enumerated state.)
- Redundancy state — is the N+1 pair still redundant, or running degraded on one?
- Input voltage — is the feed present and in range? (An electrical value.)
- Output wattage / current — how much the supply is delivering. (Electrical values.)
The electrical values follow the standard ENTITY-SENSOR pattern. The presence, status and redundancy enums mostly do not — they're vendor territory. Knowing which is which is the whole job here.
Standard vs vendor PSU data
The ENTITY-SENSOR-MIB (1.3.6.1.2.1.99) covers the electrical readings cleanly: a PSU's watts, voltsDC/voltsAC and amperes are all typed sensors with their value in entPhySensorValue (1.3.6.1.2.1.99.1.1.1.4). That part is portable.
The health picture is not. PSU presence and status enums are usually vendor-specific, published in enterprise MIBs under 1.3.6.1.4.1 rather than in one standard table. There's no universal "PSU status OID" to point at.
| Data | Source | Portable? |
|---|---|---|
| Wattage, volts, amperes | ENTITY-SENSOR-MIB (1.3.6.1.2.1.99) |
Yes — typed sensors |
| PSU presence / OK-failed status | Vendor enterprise MIB (1.3.6.1.4.1) |
No — vendor-specific enums |
| Redundancy state | Vendor enterprise MIB | No — iDRAC / iLO specific |
So the approach is: pull electrical values from ENTITY-SENSOR, and pull the status enum from your vendor's MIB — see the device pages for the exact objects.
Reading PSU sensors
Walk the sensor table and pick out the power-typed entries:
snmpwalk -v2c -c <RO_string> <host> 1.3.6.1.2.1.99.1.1.1
ENTITY-SENSOR-MIB::entPhySensorType.40 = INTEGER: watts(6)
ENTITY-SENSOR-MIB::entPhySensorValue.40 = INTEGER: 210
ENTITY-SENSOR-MIB::entPhySensorType.41 = INTEGER: voltsAC(3)
ENTITY-SENSOR-MIB::entPhySensorValue.41 = INTEGER: 231
ENTITY-SENSOR-MIB::entPhySensorType.42 = INTEGER: watts(6)
ENTITY-SENSOR-MIB::entPhySensorValue.42 = INTEGER: 0
PSU 1 (.40) is drawing 210 W with 231 VAC input; PSU 2 (.42) reads 0 watts — either failed or with no input feed. That zero on the second supply is your redundancy-loss signal. Cross-check the vendor status enum to confirm failed-versus-absent. <RO_string> is a placeholder; keep live community strings out of committed scripts.
Detecting redundancy loss
The alert that actually matters. The logic:
- Enumerate every PSU the chassis should have (its designed count).
- Poll each PSU's status enum (vendor MIB) and electrical output (ENTITY-SENSOR).
- Flag any PSU reporting not-ok, not-present, or zero output.
- Alert on a single failed/absent PSU even though the system is still up — that's the whole point.
- Escalate harder if a second PSU also drops, since you're now unprotected.
The trap to avoid is keying the alert off system availability. The server is fine on one PSU — that's what redundancy is for — so an availability check sees nothing wrong. You have to watch the PSU state directly. Route it as a "replace this week" ticket, not a page at 3 a.m., unless it's the last supply standing. See alerts.
Input voltage & wattage
Beyond pass/fail, the electrical values add context. Input voltage tells you whether the feed is healthy — a supply reading 0 VAC input has lost its circuit, which is a different problem from a supply that failed internally with good input. Output wattage trends show load balance across the pair and how close you are to a supply's rating. For the full electrical object list — voltsDC/voltsAC, amperes, watts and their decode — use the reference twin at power sensor OIDs. Rail-level voltage detail is on voltage monitoring.
Vendor specifics
Because the status and redundancy enums are enterprise-MIB objects, they differ by platform — Dell iDRAC/OpenManage, HP/HPE iLO and others each define their own PSU status codes and redundancy objects. Walk the vendor tree, confirm which index is which PSU, and map the enum values to human states once. Don't assume another vendor's status codes apply. Platform notes: devices.
Frequently asked questions
Can SNMP monitor power supplies?
Yes. Electrical values — watts, input volts, amperes — come portably from the ENTITY-SENSOR-MIB (1.3.6.1.2.1.99), and PSU presence, OK/failed status and redundancy state come from the server's vendor enterprise MIB under 1.3.6.1.4.1. Together they give a full picture of PSU health.
How do I detect a failed redundant PSU?
Enumerate the PSUs the chassis should have, poll each one's status enum and electrical output, and alert whenever any single PSU reports not-ok, not-present, or zero output — even though the system stays up on the remaining supply. Don't tie the alert to availability, because a redundant server shows no outage when one PSU dies.
What OID is PSU wattage?
Power output is an ENTITY-SENSOR-MIB sensor typed watts, with its reading in entPhySensorValue (1.3.6.1.2.1.99.1.1.1.4). Input voltage is a voltsAC/voltsDC-typed sensor in the same table. The exact index for a given PSU is device-specific.
Is PSU status standardized in SNMP?
Mostly no. The electrical values are standardized in ENTITY-SENSOR, but the presence and OK/failed status enums are vendor-specific, living in enterprise MIBs (iDRAC, iLO, etc.). There's no single universal PSU-status OID, so pull the enum from your vendor's MIB.
Key takeaways
- A dead PSU in an N+1 pair is silent — the system stays up, so you must watch PSU state directly.
- Electrical values (watts, voltsAC/DC, amperes) are portable via ENTITY-SENSOR-MIB (
1.3.6.1.2.1.99). - PSU status and redundancy enums are vendor-specific under
1.3.6.1.4.1— no universal status OID. - Alert on any single PSU failure even when the box is still up; escalate if a second drops.
- Zero input volts = lost feed; zero output watts = failed/absent supply — different problems.
- Electrical catalog: power sensors; an off-box external check via external monitoring still pages you if the host itself goes dark.