---
type: Article
title: "SNMP Temperature Monitoring"
description: "Heat degrades hardware while the dashboard stays green. There's no universal temperature OID — read CPU, intake and aisle heat via a vendor MIB or custom OID."
resource: "https://snmp-monitoring.com/sensors/environmental/temperature/"
tags: [sensors, snmp]
timestamp: 2026-07-13T00:00:00Z
---

# SNMP Temperature Monitoring

Heat is the slow killer in any rack. It doesn't crash a server the way a bad disk does — it degrades it, throttles it, and shortens its life while everything still looks green on the dashboard. SNMP temperature monitoring is how you put a number on that heat and watch it drift, whether the reading comes off a CPU die, a chassis intake, or a probe hanging in the hot aisle. Here's the honest catch, though, and it's the first thing to say plainly: temperature is *not* one of the metrics your server publishes out of the box. There's no universal OID for it. To monitor temperature over SNMP you almost always need a vendor MIB or a custom OID, and this page walks through exactly why, where to find the right object, and how to wire it up.

## What is Temperature monitoring

Temperature monitoring means polling the thermal sensors baked into your hardware — and sometimes the room around it — and turning those readings into a time series you can chart and alert on. Modern gear is stuffed with these sensors. A single server might report a CPU package temperature, several DIMM temperatures, an inlet (ambient) reading near the front bezel, an exhaust reading at the back, and a few board-level spots the vendor thought worth watching.

Why bother? Because heat behaves predictably right up until it doesn't. When a CPU crosses its thermal limit it throttles — the clock drops, throughput sags, and latency climbs — long before anything logs an error. Push further and the board triggers a protective shutdown. Sustained warmth you never notice is arguably worse: capacitors dry out, fans wear, and mean time between failures quietly falls. Inlet temperature matters just as much as component temperature, because a climbing intake reading is often the first sign of a failing CRAC unit or a blocked airflow path in the aisle.

So the value you're chasing isn't a single "is the server hot" flag. It's a set of readings, each with its own normal range, that together tell you whether the machine is comfortable, working hard, or heading for trouble. Monitor temperature over SNMP and you get that picture remotely, on a cadence you control, without logging into a single box.

![Diagram: an external SNMP poller reading a server's temperature sensor OID over UDP from outside the data-center network](https://snmp-monitoring.com/img/sensors/temperature-snmp-poll.webp)

## Why it's not in the standard host-resources MIB

The Host Resources MIB (RFC 2790) is the tree that gives you CPU load, memory, storage, and uptime — the stuff at `1.3.6.1.2.1.25.*`. People reasonably expect temperature to live there too. It doesn't. That MIB was scoped around *logical* host resources: processors as schedulable units, storage as allocation units, running software. Physical environmental readings simply weren't its job.

There's a standard home for physical sensors, mind you. The Entity Sensor MIB (RFC 3433) defines `entPhySensorValue` at `1.3.6.1.2.1.99.1.1.1.4` — a generic column meant to carry any physical sensor's current reading, temperature included. When a device implements it, that's the cleanest place to look. But — and this is the rub — RFC 3433 support is uneven. Plenty of servers, switches, PDUs, and environmental probes never populate it, exposing their thermal data through their own enterprise MIB instead.

The upshot is that temperature is an **advanced sensor**, not a default one. It won't appear in a plain walk of the standard trees, and no monitoring tool collects it automatically without being told where to look. You have to identify the specific object your hardware uses, then explicitly allow and poll it. That's more work than reading `hrProcessorLoad`, but it's completely doable — and the payoff is visibility into a failure mode that silent green dashboards routinely miss.

## Finding the right vendor OID

There's no shortcut around it: you need to know which object *your* device uses. Start with the vendor's own MIB. Hardware makers publish MIB files that document their sensor OIDs; load the right one into a MIB browser or into `snmptranslate`, and the thermal objects usually announce themselves by name. Failing that, discovery by walking works well — poke the enterprise subtree and watch for values that track the number you'd expect a temperature to be.

A practical discovery pass looks like this:

- **Try the standard first.** `snmpwalk -v2c -c public <host> 1.3.6.1.2.1.99.1.1.1` — if the Entity Sensor MIB is implemented, temperatures surface here, tagged by `entPhySensorType` (which enumerates `celsius` among its unit types).
- **Then walk the vendor's enterprise tree** under `1.3.6.1.4.1.<vendor-number>` and look for reasonable Celsius values changing slowly over time.
- **Cross-check the units.** `entPhySensorScale` and `entPhySensorUnitsDisplay` (or the vendor equivalent) tell you whether a "42" means 42 °C or 42 tenths of a degree.

The names below are real MIBs from real vendors — but the exact numeric OID and index differ by model, so treat these as where-to-look pointers, not copy-paste values. Always confirm against the MIB shipped for your device.

| Platform / vendor | MIB to consult | Typical sensor object | Notes |
|---|---|---|---|
| Standards-based (many devices) | ENTITY-SENSOR-MIB (RFC 3433) | `entPhySensorValue` (`1.3.6.1.2.1.99.1.1.1.4`) | Generic physical-sensor reading; check `entPhySensorType` = celsius |
| Linux + Net-SNMP host | LM-SENSORS-MIB | `lmTempSensorsValue` | Exposes `lm-sensors` data; index per detected sensor |
| Cisco | CISCO-ENTITY-SENSOR-MIB | `entSensorValue` | Vendor extension of the entity-sensor pattern |
| Dell servers | iDRAC / server MIB | vendor temperature-probe object | Consult the iDRAC MIB bundle for the model |
| HPE servers | CPQHLTH-MIB | thermal-temperature object | HP Insight / iLO health MIB |
| APC / Schneider PDU-UPS | PowerNet-MIB | environmental temperature object | For rack PDUs and environmental sensors |

Don't fabricate a number if you can't find the object — poll the wrong OID and you'll chart nonsense with total confidence. When in doubt, the [custom OID guide](/sensors/custom-oid.md) covers discovery in more depth.

## Setting it up as a custom OID

Once you've pinned down the object, wiring it up is mechanical. Because temperature isn't collected by default, the two things that trip people are (a) the agent not exposing the OID and (b) the poller not being told about it. Both are quick fixes.

1. **Confirm the reading by hand.** `snmpget -v2c -c public <host> <your-temperature-OID>` should return a plausible value. If it times out, the problem is reachability or community string, not the OID.
2. **Expose it in the agent.** Edit your [snmpd.conf](/setup/snmpd-conf.md) so the daemon actually serves that branch. On Linux you may also need to enable the `lm-sensors` extension for the LM-SENSORS-MIB objects to appear.
3. **Allow the OID.** Add a `view ... included` line for the exact object in your [OID allowlist](/setup/oid-allowlist.md) — a restrictive allowlist is good security, but it'll silently hide the sensor until you add it.
4. **Register it as a custom OID in your poller.** Follow [custom OID monitoring](/sensors/custom-oid.md) to add the object, label it, and set its unit so charts read in degrees rather than raw integers.
5. **Sanity-check the scale.** Some agents report tenths of a degree or apply an `entPhySensorScale` factor. Verify one known value against a physical reading before you trust the graph.

Treat this as advanced setup. It sits alongside the other physical readings you might wire the same way — you'll find the full menu in the [sensor & OID catalog](/sensors/index.md) and the flat [all sensors index](/sensors/all.md).

## Alerting

Thresholds for temperature should come from the hardware, not from a gut feel. Most vendor MIBs expose their own warning and critical limits right next to the reading, and many devices also carry an operational-status object that flips to a non-normal state when a sensor trips. Read those. They're tuned to the silicon and they beat any round number you'd invent.

For ambient and inlet readings, ASHRAE's TC 9.9 guidance is the usual reference point that facilities teams lean on for target ranges — use it as a frame, then baseline each location against its own normal. A few habits keep temperature alerts trustworthy:

- **Alert on sustained rise, not a single sample.** A brief bump during a workload spike isn't an incident; a slow climb that won't come back down is.
- **Separate inlet from component alarms.** A hot intake points at the room or airflow; a hot CPU with a cool intake points at the heatsink or a dead fan.
- **Watch the rate of change.** A fast ramp usually means a fan or airflow failure and deserves a louder page than a gentle seasonal drift.

Here's the part on-box tooling struggles with. If a server is cooking itself toward a thermal shutdown, the agent trying to warn you is running on that same overheating, throttling box — and it may lose the race. Polling from outside sidesteps that entirely. That's the reasoning behind [double durability](/monitoring/double-durability.md): an independent watcher keeps reading your temperature OID even as the host degrades. [ostr.io Monitoring](https://ostr.io/service/monitoring) polls your chosen temperature object from beyond your network and fires real-time email and SMS alerts the moment it crosses your limit, so a machine sliding toward thermal cutoff still reaches you.

![Chart: CPU and inlet temperature in Celsius over 24 hours with a warning threshold line drawn near the vendor limit](https://snmp-monitoring.com/img/sensors/temperature-chart.webp)


## FAQ

**Is there a single universal OID for temperature over SNMP?**
No. 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) — but not every device implements it, and many expose temperature through their own vendor MIB instead. You have to identify the object your specific hardware uses.

**Why doesn't temperature show up when I walk the host-resources tree?**
Because it was never part of it. The Host Resources MIB (RFC 2790) covers logical resources like CPU, memory, and storage. Physical environmental readings live in the Entity Sensor MIB or in vendor enterprise MIBs, and they aren't collected by default.

**How do I find my device's temperature OID?**
Load the vendor's 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` and look for values that behave like temperatures. Always confirm the units before trusting the number.

**What thresholds should I set?**
Prefer the warning and critical limits the vendor MIB already exposes for that sensor, since they're matched to the hardware. For ambient readings, ASHRAE TC 9.9 ranges are a common reference. Alert on sustained change rather than a single reading.

**Can I monitor room humidity and airflow the same way?**
Yes — those are sibling physical sensors handled with the same custom-OID approach. See [SNMP humidity & airflow monitoring](/sensors/environmental/humidity-airflow.md).

## Conclusion

SNMP temperature monitoring is worth the extra setup precisely because heat fails quietly. There's no default OID: you lean on the standard `entPhySensorValue` (`1.3.6.1.2.1.99.1.1.1.4`) where it's implemented, or the correct 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). Pull thresholds from the hardware, alert on sustained trends, and poll from outside the network so a server drifting toward a thermal shutdown still manages to warn you before it goes dark.