How to Monitor Proxmox Host Temperatures and Fan Speeds from the Dashboard

For a long time, host temperatures lived in the same category as many other low-level Proxmox concerns: important enough to think about, awkward enough that I only checked them when I was already uneasy.

That is not a great operational rhythm.

If a Proxmox node is always on, especially if it is a mini PC, a compact tower, or a box sitting in a less-than-perfect corner of the house, thermals are not emergency-only information. They are part of the host’s personality. A machine that runs warmer than expected, ramps its fans too often, or slowly collects dust pressure is telling you something long before it becomes a crisis.

The problem is that the built-in Proxmox summary is not the whole hardware story.

Proxmox VE can absolutely send useful host and guest metrics to external metric servers, and the official documentation covers that clearly. But if what you actually want is CPU package temperatures, board temperatures, or fan RPMs in a dashboard you check routinely, you usually need to add one more layer: Linux hardware sensors on the host, plus a simple export path to your monitoring stack.

That is the part that finally made this calm for me.

For the technical baseline below, I use Proxmox VE documentation and separate documented platform behavior from my own placement and operating recommendations.

I first assumed the Proxmox dashboard should already know this

That was my first wrong assumption.

The official Proxmox documentation makes it clear that Proxmox VE can define external metric servers that periodically receive various stats about hosts, virtual guests, and storages. That is already a strong monitoring foundation. It is one reason Proxmox does not feel like a toy. The platform understands that visibility matters and gives you a supported way to export operational data to systems such as InfluxDB and Graphite.

But temperatures and fan RPMs live slightly lower in the stack.

They depend on what the Linux host can actually see from the hardware monitoring layer. If the kernel, the board, the embedded controller, or the sensor chip does not expose those readings cleanly, no dashboard is going to invent them. That was the mindset shift that helped me: the dashboard is not the source of truth. The hardware exposure is.

Once that clicked, the problem became much simpler:

1. verify what the Proxmox host can actually read;
2. export that data in a monitoring-friendly format;
3. put it beside the rest of the host metrics I already care about.

The first real question is not dashboard design but sensor visibility

This is the part I think people should understand before they start installing extra observability tools.

If the host cannot read the data, the dashboard problem does not exist yet.

The official sensors-detect man page describes it as a program that scans the system for supported hardware monitoring chips. The sensors command then prints the current readings. That sounds small, but it is the whole foundation of the story. Before Prometheus, before Grafana, before panel design, the important question is:

"What does this host actually expose through the Linux hardware monitoring stack?"

That answer varies more than people expect.

Some systems give you CPU package temperatures quickly.
Some expose motherboard sensors but not fan RPM.
Some show NVMe temperatures nicely.
Some mini PCs reveal less than you hoped.
Some enterprise platforms want you to use a BMC path instead of the ordinary Linux sensor path.

That is not dashboard failure. It is hardware reality.

Start with lm-sensors, but do it deliberately

On a Debian-based Proxmox host, the clean first step is still lm-sensors.

apt update
apt install lm-sensors

From there, you have two different moments:

• discovering what chips and sensor paths the system supports;
• printing the actual readings you can already access.

The official sensors-detect documentation is worth respecting here because it contains an unusually honest warning. It says the tool needs hardware access to detect chips, that detection is designed to be as safe as possible, but that it cannot guarantee it will never lock or kill a specific system. It even advises against running sensors-detect on production servers.

I appreciate that warning because it keeps the workflow adult.

On a homelab Proxmox host that you can reboot if needed, I would still consider sensors-detect, but I would treat it as a planned maintenance action rather than a casual background command. On a box that truly cannot tolerate disruption, I would be much more conservative.

If you do run it:

sensors-detect

Then inspect the output with:

sensors

The Debian man page for sensors describes it very plainly: it prints sensor information. That simplicity is exactly why it is the right first checkpoint. If the values are not visible here, they are not ready for the dashboard yet.

Use JSON output if you want the exporter path to stay mature

This is one of those small details that makes the whole setup feel less fragile.

The Debian man page for sensors documents the -j option for JSON output and explicitly says it is suitable for post-processing by scripts. That is the version I trust most for exporting metrics. Parsing the plain text output can work, but it is much easier to break accidentally if labels or formatting differ between machines.

So my preferred manual check becomes:

sensors -j | jq .

You do not even need jq for the setup itself, but it is helpful for learning the structure.

At this point, you are looking for the truth that matters:

• which temperatures actually exist;
• which fan readings actually exist;
• how the chips and labels are named;
• whether the data is stable enough to be exported every minute.

If fan RPM is missing here, the dashboard will not fix that later.

Why I like node_exporter for this job

Once I know the host can read the values, I want the export path to be boring.

That is praise.

The official node_exporter documentation describes a textfile collector that reads metrics from local disk when the --collector.textfile.directory flag is set. The Debian man page also documents the textfile collector as an available collector, and the Linux thermal_zone collector is enabled by default.

That combination is useful.

It means:

• some thermal information may already exist through standard Linux collectors;
• anything more specific, especially custom fan RPM and labeled sensor values, can be written into a .prom file and scraped cleanly.

That is the path I trust most for a homelab Proxmox node because it stays readable.

A practical export pattern that stays easy to reason about

The setup I would recommend is:

1. install prometheus-node-exporter on the Proxmox host or on the system already responsible for host scraping;
2. create a textfile collector directory;
3. generate a small .prom file from sensors -j;
4. refresh it on a timer every minute;
5. scrape it with Prometheus and visualize it in your dashboard.

The directory is commonly something like:

mkdir -p /var/lib/node_exporter/textfile_collector

Then make sure node_exporter is started with the textfile directory flag:

--collector.textfile.directory=/var/lib/node_exporter/textfile_collector

From there, a small Python exporter can convert sensors -j output into Prometheus metrics:

#!/usr/bin/env python3

import json
import re
import subprocess
from pathlib import Path

OUT = Path("/var/lib/node_exporter/textfile_collector/proxmox_hwmon.prom")

def norm(value: str) -> str:
    return re.sub(r"[^a-zA-Z0-9_]", "_", value).strip("_").lower()

raw = subprocess.check_output(["sensors", "-j"], text=True)
data = json.loads(raw)

lines = []

for chip_name, chip_data in data.items():
    if not isinstance(chip_data, dict):
        continue

    chip = norm(chip_name)

    for sensor_name, sensor_data in chip_data.items():
        if not isinstance(sensor_data, dict):
            continue

        sensor = norm(sensor_name)

        for field_name, value in sensor_data.items():
            if not isinstance(value, (int, float)):
                continue

            metric_name = None

            if field_name.startswith("temp") and field_name.endswith("_input"):
                metric_name = "proxmox_host_temperature_celsius"
            elif field_name.startswith("fan") and field_name.endswith("_input"):
                metric_name = "proxmox_host_fan_rpm"

            if metric_name:
                lines.append(
                    f'{metric_name}{{chip="{chip}",sensor="{sensor}"}} {value}'
                )

OUT.write_text("\n".join(lines) + "\n", encoding="utf-8")

Then run it on a timer, for example every minute through systemd or cron.

What I like about this pattern is that it fails honestly. If the host exposes fewer readings tomorrow, the exported metrics reflect that. If a label changes, it becomes visible. Nothing magical is hiding inside a dashboard plugin.

The dashboard should answer daily questions, not only create pretty panels

This matters more than the export mechanics.

A lot of monitoring becomes decorative by accident. The graphs exist, the colors look serious, the dashboard feels advanced, and yet it does not help with the questions you actually ask during ordinary maintenance.

For host thermals, the questions I care about are simple:

• Is idle temperature gradually worse than it used to be?
• Do fans ramp earlier or harder than before?
• Does a backup window, scrub, or heavy VM burst create a thermal pattern worth remembering?
• Is one node in the lab behaving differently from similar hardware?

That is the kind of dashboard I would build.

Not ten panels because ten panels look sophisticated.

A small useful layout is enough:

1. CPU package temperature over time.
2. Motherboard or system temperature over time.
3. One panel for fan RPMs.
4. CPU usage beside temperature.
5. Optional disk or NVMe temperature panel if exposed by the host.

This also connects naturally to the broader point in the first 10 steps after installing Proxmox: a dashboard helps investigation, but only if the numbers support a decision.

Fan RPM is often the most disappointing part, and that is normal

This is the caveat I would have wanted earlier.

Temperatures are usually easier to surface than fan speeds. Fan RPM depends heavily on what the platform exposes. Desktop boards, mini PCs, enterprise systems with BMC layers, and compact OEM devices do not all tell Linux the same story.

So if you get:

• CPU and NVMe temperatures,
• perhaps a system board temperature,
• but no useful fan RPM,

that does not automatically mean your monitoring stack is broken.

It may simply mean the platform does not expose fan telemetry through the path lm-sensors can read.

This is one reason I keep coming back to the hardware realism theme from buying a first mini PC for Proxmox. A box can be great for virtualization and still be less transparent about its thermals than you hoped. Hardware elegance and observability are not always the same thing.

Why I prefer an external dashboard over trying to force everything into Proxmox itself

Because the point is not to win purity points.

The point is to see the host clearly.

Proxmox already has enough responsibilities. Its official external metric server support exists for a reason: a serious homelab eventually benefits from separating virtualization control from broader observability. Once I accepted that, trying to make the built-in Proxmox summary page carry every thermal nuance felt less important than simply having a calm dashboard I would actually open.

That is also why I think thermals belong beside backup health, storage pressure, and host load rather than in a separate forgotten corner. They are part of operations, not a side hobby.

It is the same mindset shift that made Proxmox Backup Server feel like a real operating discipline instead of a nice extra tool. Visibility gets better when it joins the routine.

What I would always keep visible now

If I were building this from scratch again, I would keep these things visible all the time:

1. CPU package temperature.
2. One ambient or motherboard-style sensor if the system exposes it.
3. Fan RPM, if available.
4. CPU utilization next to temperature.
5. A simple alert threshold for sustained abnormal heat rather than one brief spike.

That last point matters a lot.

A short spike during updates, scrubs, compaction, backups, or a noisy VM burst is not the same thing as a host that is running uncomfortably hot for an hour every evening. Trend shape matters more than isolated drama.

And that is probably the whole lesson in one sentence:

host thermal monitoring becomes useful when it stops being a nervous spot-check and starts becoming part of the ordinary daily picture.

This operating decision also connects to Server PSU Efficiency Ratings: Titanium vs Platinum at Low Percentage Loads, where the same tradeoff appears at a different layer of the homelab.

Conclusion

Monitoring Proxmox host temperatures and fan speeds becomes much easier once you stop expecting the built-in Proxmox summary to tell the whole hardware story. The reliable path is to verify what Linux can actually read through lm-sensors, export those values through a simple collector path such as node_exporter’s textfile collector, and place them in the same dashboard rhythm as CPU load, storage pressure, and backup health.

What finally changed the experience for me was not a prettier graph.

It was the realization that thermals are not special-event data. On an always-on Proxmox node, they are part of normal operational truth.

FAQ

Can Proxmox VE show temperatures and fan speeds natively in the main dashboard?

Proxmox VE can export many host and guest metrics to external metric servers, but thermal and fan telemetry usually needs a separate Linux sensor collection path if you want a mature dashboard experience.

What should I install first on the Proxmox host?

Start with lm-sensors, because the first important step is verifying what the host can actually read before building the monitoring pipeline around it.

Why do I see temperatures but no fan RPM?

That often comes down to hardware exposure. Some systems expose temperatures through Linux hardware monitoring, but do not expose fan telemetry in a way lm-sensors can read.

Is the textfile collector a good choice for this?

Yes, especially in a homelab. It keeps the pipeline simple, readable, and easy to debug, which is often better than hiding sensor collection inside a heavier abstraction.

How often should these values be refreshed?

Every minute is usually enough for a homelab dashboard. The goal is not oscilloscope-level detail but dependable operational visibility and trend awareness.