By the SNMP Monitoring team · Reviewed July 2026
Fan speed rides the same generic sensor machinery as temperature — the ENTITY-SENSOR-MIB — just typed rpm instead of celsius. This page is the paste-ready reference for the RPM objects, the Linux LM-SENSORS fan variant, and where vendor fan OIDs live. The nice thing about RPM: it's a plain integer count, so unlike temperature there's usually no fractional scaling to fight with — the value is the RPM.
The "how do I alert on a dying fan" side is the twin: monitor fan speed. Hubs: sensors, all OIDs.
ENTITY-SENSOR rpm objects
A fan is an entry in the sensor table at 1.3.6.1.2.1.99.1.1.1 whose entPhySensorType reads rpm. Same columns as any physical sensor:
| Object | OID | Meaning / type |
|---|---|---|
| entPhySensorType | 1.3.6.1.2.1.99.1.1.1.1 | Sensor type — rpm(10) for fans |
| entPhySensorScale | 1.3.6.1.2.1.99.1.1.1.2 | SI multiplier (usually units for RPM) |
| entPhySensorPrecision | 1.3.6.1.2.1.99.1.1.1.3 | Decimal places (usually 0 for RPM) |
| entPhySensorValue | 1.3.6.1.2.1.99.1.1.1.4 | The RPM reading (integer) |
| entPhySensorOperStatus | 1.3.6.1.2.1.99.1.1.1.5 | Sensor status (ok / unavailable) |
Because RPM is a whole-number count, scale is typically units and precision 0, so entPhySensorValue is the RPM as-is. Still read entPhySensorOperStatus — an unavailable sensor means "no reading," which is not the same as a fan at 0 RPM.
That distinction matters more for fans than for most sensors, and it's worth dwelling on. Both "sensor unavailable" and "fan stopped" can surface as an absent or zero reading, but they demand opposite responses: a stopped fan is a hardware failure you replace, while an unavailable sensor is a monitoring gap you investigate on the reporting side. If you alert purely on entPhySensorValue == 0 without checking entPhySensorOperStatus, you'll conflate the two — paging someone to swap a perfectly good fan because a sensor dropped offline, or worse, dismissing a real dead fan as "probably just the sensor." So the reliable read is a pair: confirm the status is ok, then trust the RPM value. When the status is anything other than ok, treat the reading as suspect and chase the sensor path, not the fan.
LM-SENSORS fan OIDs
On Linux hosts running Net-SNMP with the lm-sensors module, fans also appear in the LM-SENSORS-MIB alongside temperatures:
- lmFanSensorsValue —
1.3.6.1.4.1.2021.13.16.3.1— fan RPM values fromlm-sensors.
This is the Linux path to fan RPM without a vendor MIB, useful on a server where the board's fans are exposed through lm-sensors. Like the temperature variant, it's Net-SNMP-specific and requires the module be enabled in snmpd.conf, so you won't see it on network gear.
Vendor fan OIDs
Labelled, per-fan data with health enums usually comes from a vendor enterprise MIB under 1.3.6.1.4.1:
- HP/HPE iLO, Dell iDRAC, and Supermicro each expose their own fan objects — named fans, per-fan status, sometimes redundancy state — often mirroring the platform's IPMI fan list.
The exact fan leaf differs per device, so this reference doesn't fabricate one. Learn the ENTITY-SENSOR/LM-SENSORS pattern here, then read the precise labelled objects from the device pages for your hardware. Confirm which index maps to which physical fan by walking the tree, not by copying a leaf from elsewhere.
Worked snmpwalk example
Walk the sensor table and pick out the rpm 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
Two fans near 5,200 RPM and fan .23 at 0 — dead or pulled. To learn which physical fan .23 is, cross-reference the index against the ENTITY-MIB inventory at 1.3.6.1.2.1.47. <RO_string> is a placeholder; keep live communities out of committed scripts.
Interpreting rpm
The RPM number tells two different failure stories:
- 0 RPM on a fan that should spin — an unambiguous failure on a non-variable fan. Alert immediately.
- Below the normal floor — a fan idling around 5,000 now reading 1,800 is failing, not yet dead. Catch it with a per-fan floor threshold.
- Sustained maximum RPM — every fan pinned at full usually means the box is hot and cooling is compensating; the fan is fine, so treat it as a thermal signal and check temperature.
The subtlety: don't average fan RPM across the chassis, because averaging hides the single dead fan that matters most in an N+1 cooling setup. Read each fan individually — one at 0 among seven healthy ones still needs a same-week replacement before you lose the redundancy.
How to monitor fans (how-to)
Reference stops here. The alerting logic — floor thresholds, N+1 single-failure alerts, all-fans-at-max as a thermal warning — is the twin: monitor fan speed via SNMP. Related: temperature OIDs, power OIDs, the OID catalog, and glossary.
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. On Linux with lm-sensors, lmFanSensorsValue (1.3.6.1.4.1.2021.13.16.3.1) works too; labelled per-fan data comes from vendor MIBs.
What MIB has fan sensors?
The standard is the ENTITY-SENSOR-MIB at 1.3.6.1.2.1.99, which types sensors including rpm. Linux hosts also expose fans through the LM-SENSORS-MIB, and vendors publish labelled fan objects with health enums under their enterprise arc 1.3.6.1.4.1.
What's the Linux fan speed OID?
On a Net-SNMP host with the lm-sensors module enabled, lmFanSensorsValue (1.3.6.1.4.1.2021.13.16.3.1) exposes the lm-sensors fan RPM values. It requires the module be configured in snmpd.conf, and the index-to-fan mapping is device-dependent, so confirm it on your hardware.
What does 0 RPM mean?
On a non-variable fan, 0 RPM means the fan has failed or been removed — it's an unambiguous failure worth an immediate alert. First, though, check entPhySensorOperStatus: if the sensor reports unavailable rather than a real reading, that's a sensor/reporting issue, not necessarily a stopped fan.
Key takeaways
- Fan speed is portable via ENTITY-SENSOR-MIB —
entPhySensorValue1.3.6.1.2.1.99.1.1.1.4, typerpm. - RPM is a whole number — scale
units, precision0— so the value is the RPM. - Linux/lm-sensors:
lmFanSensorsValueat1.3.6.1.4.1.2021.13.16.3.1. - Exact fan leaves are vendor-specific under
1.3.6.1.4.1— don't copy a leaf, walk the tree. - 0 RPM = failure, below-floor = failing, all-max = a thermal signal; never average fans.
- Procedure: fan-speed how-to; catalog: sensors/all.