--- type: Article title: "SNMP Fan Speed Monitoring" description: "A dead fan cooks the parts behind it within minutes. Fan RPM is a leading indicator — read it over SNMP via a vendor MIB or custom OID before heat climbs." resource: "https://snmp-monitoring.com/sensors/environmental/fan-speed/" tags: [sensors, snmp] timestamp: 2026-07-13T00:00:00Z --- # SNMP Fan Speed Monitoring A fan is the cheapest part in the whole chassis and, when it dies, one of the most dangerous. Lose airflow and the components downstream of that dead fan start climbing toward their thermal limits within minutes. SNMP fan monitoring is how you catch that failure while it's still just a dropped RPM reading and not yet a throttled CPU or a protective shutdown. The awkward truth up front: fan speed isn't a metric your server hands out automatically. There's no universal OID for it, so to monitor fan speed over SNMP you'll be reaching for a vendor MIB or wiring up a custom OID — and this page covers exactly how that's done. ## What is Fan Speed monitoring Fan speed monitoring means reading the tachometer signal each cooling fan produces, usually reported in revolutions per minute, and tracking those RPM values over time. A typical server carries a bank of hot-swap fans; enterprise switches and chassis have fan trays; PSUs have their own small fans. Each one that reports a tach signal is a sensor you can poll. The reading itself is simple, but what it *tells* you is layered. A fan spinning at its expected RPM means airflow is doing its job. A fan reading zero, or wildly below its neighbours, means that unit has failed or stalled — and because cooling is usually zoned, one dead fan can leave a specific set of components under-cooled while the rest of the box looks fine. A fan pinned at maximum RPM for no obvious reason is its own signal: the thermal management is fighting rising heat, which points back at a clogged filter, a hot room, or another failed fan picking up the slack. That's the real value here. Fan RPM is a leading indicator. It moves *before* temperature does, because the cooling system ramps up to defend the setpoint. Watch fan speed over SNMP and you often see trouble coming a step earlier than a thermal sensor alone would show it — which, when you're trying to prevent a shutdown rather than react to one, is exactly the head start you want. ![Diagram: an external SNMP poller reading a server's fan tachometer OID over UDP, with one fan in the tray showing zero RPM](https://snmp-monitoring.com/img/sensors/fan-snmp-poll.webp) ## Why it's not in the standard host-resources MIB The trees everyone knows — the Host Resources MIB (RFC 2790) at `1.3.6.1.2.1.25.*` for CPU, memory, and storage, plus MIB-II for interfaces — model the *logical* and network-facing side of a device. A fan's rotational speed is a physical, electromechanical property. It was simply never in scope for those standards, so a plain walk of the host-resources tree returns nothing about cooling. Where fans *do* have a standard home is the Entity Sensor MIB (RFC 3433). Its generic reading column, `entPhySensorValue` at `1.3.6.1.2.1.99.1.1.1.4`, can carry an RPM value, with the companion `entPhySensorType` object flagging the unit as `rpm`. When a device implements RFC 3433, that's the tidy place to poll. The problem is coverage: many servers and switches don't populate the entity-sensor tree at all and instead expose fan status through their own enterprise MIB. So fan speed lands in the **advanced sensor** category — not collected by default, invisible to a generic scan, and specific to your hardware. No monitoring platform picks it up automatically; you have to identify the exact object your gear uses, permit it, and poll it deliberately. It's a little more legwork than the built-in metrics, but it buys you eyes on a component that fails often and fails fast. ## Finding the right vendor OID The job is to match your specific hardware to its fan object. The vendor MIB is the authoritative source — load the file into a MIB browser or `snmptranslate` and the fan entries usually carry obvious names. If you can't get the MIB, discovery by walking is reliable, because fan RPM values are distinctive: they sit in the thousands and shift when the cooling ramps. Run discovery roughly like this: - **Check the standard tree first.** `snmpwalk -v2c -c public 1.3.6.1.2.1.99.1.1.1` — where RFC 3433 is implemented, fans appear with `entPhySensorType` = `rpm`. - **Then walk the vendor enterprise subtree** under `1.3.6.1.4.1.`, watching for values in the RPM range that respond when the box heats up. - **Look for a companion status column.** Fan objects often sit beside an operational-status field that reads `ok`, `failed`, or `notPresent` — invaluable for alerting. The MIBs below are real and vendor-published, but the precise numeric OID and per-fan index vary by model. Use this as a map of where to look, and confirm every value against the MIB shipped for your device rather than pasting a number. | Platform / vendor | MIB to consult | Typical fan object | Notes | |---|---|---|---| | Standards-based (many devices) | ENTITY-SENSOR-MIB (RFC 3433) | `entPhySensorValue` (`1.3.6.1.2.1.99.1.1.1.4`) | Generic reading; `entPhySensorType` = rpm marks a fan | | Linux + Net-SNMP host | LM-SENSORS-MIB | `lmFanSensorsValue` | Surfaces `lm-sensors` fan tachometers by index | | Cisco | CISCO-ENTITY-SENSOR-MIB / CISCO-ENVMON-MIB | `entSensorValue` / fan-state object | Fan state plus RPM on many platforms | | Dell servers | iDRAC / server MIB | fan-probe object | Consult the iDRAC MIB bundle for the model | | HPE servers | CPQHLTH-MIB | fan-status object | HP Insight / iLO health MIB | | Juniper | JUNIPER-MIB | fan operating object | Chassis fan trays via the operating table | Guessing a number here is worse than useless — you'll chart a value that isn't a fan and never know. If the object won't reveal itself, the [custom OID guide](/sensors/custom-oid.md) goes deeper on discovery technique. ## Setting it up as a custom OID With the correct object identified, the setup is short. The two usual snags are the agent not serving the branch and a strict allowlist hiding it, and both are one-line fixes. 1. **Verify by hand.** `snmpget -v2c -c public ` should return a believable RPM. A timeout means reachability or community trouble, not a bad OID. 2. **Serve the branch in the agent.** Update your [snmpd.conf](/setup/snmpd-conf.md) so the daemon exposes it; on Linux hosts you may need the `lm-sensors` extension enabled for LM-SENSORS-MIB fan objects to show. 3. **Allow the OID explicitly.** Add a `view ... included` entry for the exact object in your [OID allowlist](/setup/oid-allowlist.md); until you do, a tight allowlist will keep the fan hidden. 4. **Register it as a custom OID.** Use [custom OID monitoring](/sensors/custom-oid.md) to add the object, name each fan sensibly, and set RPM as the unit. 5. **Pull in the status column too.** If the hardware exposes a fan operational-status object, poll it alongside the RPM — a state flag is often a cleaner alert trigger than a raw number. This is advanced wiring by design, and it lives next to the other physical sensors you might set up the same way. Browse the neighbours in the [sensor & OID catalog](/sensors/index.md) or the flat [all sensors index](/sensors/all.md). ## Alerting The most useful fan alert is rarely "RPM below X." It's **zero, or drastically out of family.** A single fan reading 0 while its siblings hum along at a few thousand RPM is a failed unit, full stop — and if the device exposes a fan status object, a flip to `failed` or `notPresent` is the crispest trigger you can ask for. Let the hardware's own thresholds guide the numeric bands where they're published; they're tuned to the chassis airflow design. Beyond the single-fan case, a few patterns are worth alarming on: - **All fans ramping to maximum together** — the cooling system is compensating for rising heat somewhere. Correlate it with [temperature readings](/sensors/environmental/temperature.md). - **One fan persistently lagging the group** — early bearing wear, often before it fails outright. - **A fan flapping between speeds** — an intermittent tach or a dying fan that can't hold a setpoint. And here's why watching from outside matters. A fan failure that leads to overheating puts the on-box agent in a bad spot — it's running on hardware that's throttling and may shut down before its warning ever leaves the building. External polling avoids that dependency. It's the logic behind [double durability](/monitoring/double-durability.md): an independent checker keeps reading your fan OID even as the machine degrades. [ostr.io Monitoring](https://ostr.io/service/monitoring) polls the object from outside your network and sends real-time email and SMS alerts the instant a fan drops out, so a cooling failure reaches you before the thermal cascade finishes the job. ![Chart: fan speed in RPM across four chassis fans over 24 hours, one line dropping to zero to indicate a failed fan](https://snmp-monitoring.com/img/sensors/fan-rpm-chart.webp) ## FAQ **Is there a standard OID for fan speed?** There's a standard *object* — `entPhySensorValue` at `1.3.6.1.2.1.99.1.1.1.4` in the Entity Sensor MIB (RFC 3433), with `entPhySensorType` set to `rpm` for a fan — but it's not universally implemented. Many devices report fan speed through a vendor MIB instead, so you must identify what your hardware uses. **Why isn't fan speed in the host-resources MIB?** The Host Resources MIB (RFC 2790) models logical resources — CPU, memory, storage — not physical electromechanical parts. Fan RPM belongs to the Entity Sensor MIB or a vendor enterprise MIB and isn't collected by default. **A fan reads zero — is that always a failure?** Almost always, if its siblings are spinning. A genuine zero next to healthy fans means a stalled or dead unit. Some designs park a redundant fan at zero until needed, so check the fan status object if the device exposes one before you page. **How do I discover my device's fan OID?** Load the vendor MIB into a browser or `snmptranslate`, or walk `1.3.6.1.2.1.99.1.1.1` and the vendor enterprise subtree with `snmpwalk`, looking for values in the RPM range plus any adjacent status column. **Should I alert on RPM or on fan status?** Use both if you can. A status flag flipping to `failed` is the cleanest trigger; the RPM series is what shows gradual wear and lets you spot a fan drifting before it dies. ## Conclusion SNMP fan monitoring pays for its setup effort because a fan failure is an early, fast-moving warning of heat trouble. There's no default OID: use the standard `entPhySensorValue` (`1.3.6.1.2.1.99.1.1.1.4`) where RFC 3433 is implemented, or the right 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). Alert on zero and on out-of-family readings, lean on the device's status column, and poll from outside so a cooling failure warns you before the box overheats and goes silent.