How to monitor server rack temperature over SNMP
Overheating is the quiet killer of server rooms: it shortens hardware life, throttles performance, and the first sign is often a failure, not a warning. This guide covers what to measure, where to put sensors, what thresholds are safe, and how polling and alerting should actually behave — so you know a rack is heating up long before anything trips.
1. What to actually measure: rack inlet temperature
“Room temperature” from one wall sensor is nearly useless — air stratifies and a single hot rack can cook while the room reads fine. Measure at the equipment, per rack:
- Intake (cold aisle) temperature — the air your gear is breathing. This is the number ASHRAE guidance is written against.
- Exhaust (hot aisle) temperature — how hot the air leaves. A widening intake-to-exhaust delta can signal airflow problems or a failing fan.
- Per-device sensors — most servers, switches and PDUs expose inlet/CPU/board temperatures over SNMP. Poll them; they’re free data.
- Top / middle / bottom of the rack — heat rises, so the top U’s run hottest. One sensor mid-rack hides the worst spot.
If you only ever measure one thing, measure the inlet. It is the number every published limit is written against, and it is the only one that tells you about the room rather than about the workload. A CPU at 70 °C under load is a CPU doing its job; the same server with 35 °C going into it is a room in trouble, and the CPU reading will not tell you which of the two you are looking at.
Where to put the probe matters as much as having one. Inlet means at the front face of the rack, in the cold aisle, at the height of the equipment — not on the wall, not above the rack, not behind it. Three probes per rack (top, middle, bottom) cost very little and catch the thing a single mid-rack sensor is blind to: the top U’s running five to eight degrees hotter than the middle because heat rises and recirculates over the top of the rack. If you can only fit one, put it at the top, because that is where the trouble starts.
Most gear will give you an inlet reading over SNMP without any extra hardware. The sensor is already in there: Dell calls it System Board Inlet Temp, HPE calls it 01-Inlet Ambient, and APC rack PDUs expose an ambient probe. The traps are in the details — which sensor index is actually the inlet, and whether the value comes back in whole degrees or tenths — and those are spelled out per vendor in the OID reference and the step-by-step guides above.
2. Safe thresholds, and the ASHRAE envelope they come from
ASHRAE’s widely-used “recommended” envelope for data-center intake air is roughly 18–27 °C (64–80 °F), with an “allowable” range that goes higher for short periods. For a mixed SMB/edge room, sensible alert bands are:
| Intake temperature | Status | Action |
|---|---|---|
| ≤ 27 °C / 80 °F | Nominal | None |
| 27–32 °C / 80–90 °F | Warning | Investigate airflow / cooling |
| ≥ 32 °C / 90 °F | Critical | Act now — cooling likely failing |
Treat these as a starting point, not gospel — check your hardware vendors’ own inlet limits and your local ASHRAE class. The point is to alert on intake, at the rack, with a margin before hardware limits.
Where 27 °C comes from
Those bands are not arbitrary. ASHRAE’s Technical Committee 9.9 publishes a thermal envelope for data-centre equipment that almost every hardware vendor writes its own warranty limits against, and it has two parts. The recommended range is where you should normally sit; it is the same for every equipment class, because it is about running cost and component life rather than survival. The allowable range is what the hardware is specified to tolerate — excursions, not a place to live.
| Envelope | Intake dry-bulb | Relative humidity | Max dew point |
|---|---|---|---|
| Recommended (all classes) | 18–27 °C / 64–81 °F | up to 60 % RH | 15 °C / 59 °F |
| Allowable, class A1 (enterprise servers, storage) | 15–32 °C / 59–90 °F | 20–80 % | 17 °C / 63 °F |
| Allowable, class A2 (volume servers, most SMB rooms) | 10–35 °C / 50–95 °F | 20–80 % | 21 °C / 70 °F |
| Allowable, class A3 | 5–40 °C / 41–104 °F | 8–85 % | 24 °C / 75 °F |
| Allowable, class A4 | 5–45 °C / 41–113 °F | 8–90 % | 24 °C / 75 °F |
Figures as widely published for the ASHRAE TC 9.9 classes; check the current edition and your own hardware’s datasheet before treating any of them as a contractual limit. Most mixed SMB and edge rooms are running class A2 gear, which is why 27 °C makes a good warning line and 32 °C a good critical one: 32 is the top of A1’s allowable range, so by then you are outside what some of the kit in a typical mixed rack is specified for.
Two practical consequences people miss. First, the allowable range is not free: equipment inside it is within spec, but server fans ramp hard above roughly 25–30 °C intake, so you pay for the warmer room in fan power and in noise, and you lose thermal headroom for the next cooling failure. Second, the limits are about intake air, not about the room. A room averaging 22 °C with one rack recirculating its own exhaust can be feeding 35 °C into the top of that rack — comfortably outside A2 — while the wall thermostat reads fine.
3. Why SNMP
SNMP (Simple Network Management Protocol) is the lingua franca of infrastructure telemetry. Almost everything in a rack — servers’ BMC/iDRAC/iLO, managed switches, UPSs, PDUs and dedicated temperature/humidity probes — can expose readings over SNMP. Two versions matter:
- SNMP v2c — simple, community-string based, unencrypted. Fine on a trusted management VLAN.
- SNMP v3 — adds authentication and encryption (authPriv). Prefer it anywhere the management network isn’t fully isolated.
You read a device’s temperature by polling its OID (object identifier). Vendors publish these in MIBs; a sensor probe might expose intake temperature at an OID you poll every 15–60 seconds.
The OIDs you actually need
Most guides stop at “poll the vendor’s OID” without telling you which one. Here are the real ones.
Start with the standard, not the vendor. RFC 3433 defines a vendor-neutral sensor table, and a surprising amount of modern gear implements it. If it answers, you can use one OID across your whole estate instead of a different one per brand:
# every sensor value the device exposes
snmpwalk -v2c -c public 10.0.0.10 1.3.6.1.2.1.99.1.1.1.4
# the human-readable names, so you know which index is the inlet
snmpwalk -v2c -c public 10.0.0.10 1.3.6.1.2.1.47.1.1.1.1.2
On SNMP v3 the same walk becomes:
snmpwalk -v3 -l authPriv -u monitor -a SHA -A '<auth-pass>' -x AES -X '<priv-pass>' 10.0.0.10 1.3.6.1.2.1.99.1.1.1.4
Match the index from the second walk (something like “Inlet Temp” or “Ambient Zone”) to the index in the first, and you have your inlet reading.
Common vendor OIDs
The one you need depends on the hardware, and the number it returns is not always the number
you think. Dell iDRAC reports tenths of a degree — a returned 275 is
27.5 °C, not 275 °C. An APC card set to Fahrenheit will hand you 78 for a
perfectly normal room and let a threshold of 32 never fire.
We keep the full list in one place:
SNMP temperature OIDs by vendor — Dell iDRAC,
HPE iLO, Cisco, Juniper, APC and the vendor-neutral standard, with the scaling and unit traps
spelled out for each and copy-paste snmpwalk commands.
And if you already know what you are pointing at, there is a step-by-step walkthrough for each: reading inlet temperature from a Dell PowerEdge over iDRAC, the same for an HPE ProLiant over iLO (including how to tell which sensor is the ambient one), and APC rack PDUs and NMC probes, where the same column exists in Celsius and Fahrenheit and picking the wrong one is quietly catastrophic.
Verify before you trust any of these. OIDs shift between models and firmware revisions, and the two things that most often go wrong are scaling (a value of 275 meaning 27.5 °C) and units (a card quietly reporting °F). Walk the OID on your own hardware, compare it against what the device’s own web UI shows, and only then wire it into alerting. A threshold built on a mis-scaled reading is worse than no monitoring at all, because you will trust it.
If you would rather not maintain this mapping by hand, that is precisely what RackMon ships: per-vendor OID profiles, inlet and device temperature tracked separately, and a per-U heatmap so the hot node is obvious without reading a chart. There is a live read-only demo with real data. If you are weighing it against the usual suspects, the comparison with Zabbix, PRTG, LibreNMS and Checkmk is the honest version, and the FAQ covers licensing and what the free Community edition includes.
4. Setting up monitoring
- Put your management interfaces on a dedicated VLAN and allow your monitor to reach them on UDP/161.
- Enable SNMP on each device (v3 with authPriv where you can) and note the temperature OIDs.
- Add a few temperature/humidity probes per rack (intake + exhaust) if your gear doesn’t already expose good inlet sensors.
- Poll on a sensible interval — 15–60s is plenty for thermals; you’re watching a slow-moving physical quantity.
- Store history so you can see trends, not just the current number — the week-long climb matters as much as the spike.
5. Alerting that you’ll actually trust
Bad alerting trains people to ignore alerts. Good rack-thermal alerting should:
- Use hold windows — don’t fire on a single stray reading; require the condition to persist (e.g. 2–3 minutes).
- Deduplicate and correlate — ten devices in one rack going hot is one incident, not ten pages.
- Never fake a recovery — a missed poll or a maintenance window is “no data”, not “all clear”.
- Escalate — email first, then chat (Slack/Teams/Telegram) or a webhook if unacknowledged.
6. Reading the numbers: delta-T, stratification and humidity
A single intake number tells you whether you have a problem right now. Two or three numbers together tell you what the problem is, which is the difference between knowing a rack is hot and knowing what to go and fix.
Intake-to-exhaust delta-T
Subtract the intake temperature from the exhaust temperature of the same device. Under normal load a server typically raises the air passing through it by something in the region of 10–20 °C. That figure is a diagnostic in its own right, and it moves in the opposite direction to what most people expect:
| What you see | Usually means | Where to look first |
|---|---|---|
| Intake high, delta-T normal | The room is feeding the rack warm air. The rack itself is fine. | Cooling capacity, a failed CRAC/split unit, outside conditions |
| Intake high, delta-T low | Recirculation: the rack is breathing its own exhaust. | Missing blanking panels, gaps beside rails, open rear door, no hot/cold aisle containment |
| Intake normal, delta-T high | Not enough air moving through the box for the heat it is making. | Failed or throttled fan, blocked filter, cable bundle across the exhaust, dust |
| Delta-T high and climbing slowly over days | Progressive restriction, not an event. | Filters and dust; compare against the same device a month ago |
| Delta-T suddenly near zero on a live device | Almost always a sensor, not physics. | The probe itself — a device reporting the same number on two sensors is reporting one sensor twice |
This is also why exhaust sensors earn their place even though no published limit is written against them: on their own they tell you little, but paired with the intake they separate “the room is too hot” from “this box is choking”, and those two faults have nothing in common except the alert they trigger.
Top-to-bottom stratification
Hot air rises, so the top of a rack runs warmer than the bottom — in a room with decent airflow, typically by a few degrees; in a room with poor containment it is routinely 5–8 °C and can be far more. The number matters because it decides where your sensor goes. A probe at mid-height in a rack with 8 °C of stratification reads about 4 °C cooler than the air going into the equipment that is actually at risk, and 4 °C is the entire distance between a nominal reading and a warning. If you fit one probe per rack, fit it at the top of the equipment, not in the middle of the cabinet. If you fit two, put the second at the bottom and watch the gap: a widening top-to-bottom spread is an airflow problem arriving long before either number crosses a threshold.
Humidity, which is slower and costs more
Temperature kills hardware quickly enough that it gets all the attention, but the ASHRAE envelope has a humidity axis for a reason, and both ends of it are expensive. Too dry and you get electrostatic discharge during handling; too damp and you get corrosion on contacts and boards, which does not announce itself until something fails for no visible reason months later. The recommended ceiling is a 15 °C dew point and 60 % RH; the allowable band for class A1 and A2 runs 20–80 % RH.
Watch the dew point rather than the relative humidity if you can get it. Relative humidity changes when the temperature changes even though the amount of water in the air has not moved at all, so an RH reading that drifts all day may be telling you about your cooling cycle rather than about moisture. Dew point does not move with temperature, which makes it both a better alarm and a much better thing to put on a trend graph. Most combined temperature/humidity probes report both over SNMP; if yours reports only RH and temperature, the dew point is derivable from the pair and worth deriving.
7. Reporting
If you host for clients (colocation, MSP), turn the data into something they’ll accept: availability and SLA-compliance figures, per-device downtime, and a read-only public status page so tenants can self-serve instead of emailing you.
The fast path
You can build all of the above with a general-purpose monitoring stack — or you can run a tool that’s already shaped around this exact job. RackMon is a self-hosted monitor that does rack thermals + SNMP v2c/v3 out of the box: a live per-U heatmap of every rack, honest alerting (hold windows, dedup, no fake “recovered”), SLA/uptime PDF reports and a public status page — in a single container, in about ten minutes. The Community edition is free forever.