By the SNMP Monitoring team · Reviewed July 2026
A fan is the one server component almost guaranteed to fail before anything else — it's the only part with a bearing spinning thousands of times a minute, all day, for years. And when it goes, you often don't find out from the fan; you find out from a CPU throttling or a thermal alarm minutes later, after damage is already accumulating. Fan RPM is the signal that gets ahead of that. SNMP reads it straight off the same sensors the board uses for cooling control, so a stalled or struggling fan shows up as a number long before heat does.
This is the how-to. The object catalog lives on the reference twin, fan-speed sensor OIDs. Parent: hardware monitoring.
Where fan speed lives in SNMP
Fans follow the same generic pattern as every other physical sensor: the ENTITY-SENSOR-MIB (1.3.6.1.2.1.99). A fan is simply a sensor whose entPhySensorType reads rpm, with its reading in entPhySensorValue (1.3.6.1.2.1.99.1.1.1.4). Because RPM is a whole-number count with no fractional part, the scale and precision decode is usually trivial — the value is the RPM.
As with temperature, many servers expose richer, labelled fan data through their enterprise MIBs under 1.3.6.1.4.1 — HP iLO, Dell iDRAC, Supermicro — often with per-fan names and a health status enum on top of the raw RPM. The exact fan OID indexes are device-specific, so read the pattern here and pull the precise objects from the device pages for your hardware.
Reading fan RPM
Walk the sensor table and pick out the rpm-typed entries:
snmpwalk -v2c -c <RO_string> <host> 1.3.6.1.2.1.99.1.1.1
ENTITY-SENSOR-MIB::entPhySensorType.21 = INTEGER: rpm(10)
ENTITY-SENSOR-MIB::entPhySensorValue.21 = INTEGER: 5200
ENTITY-SENSOR-MIB::entPhySensorType.22 = INTEGER: rpm(10)
ENTITY-SENSOR-MIB::entPhySensorValue.22 = INTEGER: 5120
ENTITY-SENSOR-MIB::entPhySensorType.23 = INTEGER: rpm(10)
ENTITY-SENSOR-MIB::entPhySensorValue.23 = INTEGER: 0
Three fans: two spinning near 5,200 RPM, and fan .23 at 0 — dead, or pulled. To know which physical fan .23 is, cross-reference the index against the ENTITY-MIB inventory at 1.3.6.1.2.1.47 and label it once, so the alert says "Fan 3" and not "sensor 23." <RO_string> is a placeholder; keep live community strings out of committed scripts.
Detecting a stalled or runaway fan
RPM tells two different failure stories depending on which direction it moves:
- Zero (or near-zero) RPM on a fan that should be spinning — it stalled or died. On a non-variable fan, 0 RPM is an unambiguous failure. Alert immediately.
- A drop below its normal floor — say a fan that idles around 5,000 RPM now reads 1,800. It's failing, not yet dead. Catch this with a per-fan floor threshold, not just a zero check.
- Sustained maximum RPM — every fan pinned at full tilt usually means the box is hot and cooling is compensating. The fan itself is fine; treat it as a thermal warning and go look at temperature.
So the alert logic is two-sided: floor thresholds catch a dying fan, and a "all fans at max" condition catches a thermal problem the fans are papering over. A single fan reading zero is the clearest signal of all.
Redundant fans
Server cooling is almost always N+1 — there are more fans than the thermal design strictly needs, so one can fail and the box keeps running. That redundancy is exactly why fan monitoring gets ignored: nothing breaks when the first fan dies, so nobody notices until the second one goes and now you're under-cooled with no margin.
The rule that fixes it:
- Alert on any single fan failure, even when the system is still happily cooled.
- Don't wait for a thermal alarm — by then you've already burned your redundancy.
- Track each fan individually so "one of eight failed" is visible, not averaged away.
- Treat the first failure as a same-week replacement, not an emergency — but never as "ignore."
Averaging fan RPM across the chassis hides exactly the thing you care about. Watch them per-fan.
Vendor specifics
Labelled fans and their health enums live in enterprise MIBs, so the objects differ by platform:
| Platform | Fan data source | Extras beyond RPM |
|---|---|---|
| HP/HPE iLO | Enterprise health MIB under 1.3.6.1.4.1 |
Named fans, per-fan status enum |
| Dell iDRAC / OpenManage | Enterprise cooling-device objects | Location labels, redundancy state |
| Supermicro | Enterprise sensor tree | Often mirrors the IPMI fan list |
Confirm the exact index-to-fan mapping on your gear rather than trusting a copied OID. Platform notes: devices.
Reference
This is the fan-speed how-to. For the full object list and types, use the reference twin: fan-speed sensor OIDs. Related: temperature and power supply. Definitions at glossary; full index at all sensors.
Frequently asked questions
What OID is fan speed in SNMP?
The portable one is entPhySensorValue (1.3.6.1.2.1.99.1.1.1.4) from the ENTITY-SENSOR-MIB, for any sensor whose entPhySensorType is rpm. Labelled per-fan data with a health status usually comes from a vendor enterprise MIB under 1.3.6.1.4.1; the exact index is device-specific.
How do I detect a failed fan?
Alert on 0 RPM for a fan that should be spinning — on a non-variable fan that's an unambiguous failure — and also on a drop below the fan's normal RPM floor to catch one that's failing but not yet dead. Watch each fan individually so a single failure in an N+1 group is visible.
Can SNMP read server fan RPM?
Yes. Fans appear in the ENTITY-SENSOR-MIB typed as rpm, and server platforms expose them through their enterprise MIBs too. Reading RPM directly is the earliest warning of a cooling problem, well ahead of any thermal alarm.
Why is my fan running at max RPM?
Sustained maximum RPM across the fans usually means the hardware is hot and the cooling system is ramping up to compensate — the fans are working, not failing. Treat it as a thermal signal and investigate temperature and airflow rather than the fan itself.
Key takeaways
- Fan speed is portable via ENTITY-SENSOR-MIB (
entPhySensorValue1.3.6.1.2.1.99.1.1.1.4, typerpm). - 0 RPM on a non-variable fan = failure; a drop below the normal floor = failing. Alert on both.
- All fans at max = a thermal problem, not a fan fault — check temperature.
- Cooling is N+1: alert on any single fan failure before you lose the redundancy.
- Watch fans per-fan, not averaged; map the index to a real fan label once.
- Object catalog: fan-speed sensors; an off-box external check via external monitoring still pages you if the host itself drops.