nvidia-smi shows Fan: 0% and the GPU is sitting at 70C under load. Either the fan is dead, or the card is doing exactly what its firmware told it to do. Telling those two apart quickly is the whole job: the wrong guess in one direction means a cooked GPU, the wrong guess in the other means a pointless RMA.
A healthy air-cooled card spins its fans up as the die warms and spins them down at idle. Zero RPM while the GPU is above idle temperature is a failed fan until proven otherwise. Sustained 100% with temperature still climbing is the opposite failure: the fan works but cooling capacity is exceeded.
This article applies to consumer and workstation cards (GeForce, RTX A-series, A6000-class) with onboard fans. Most datacenter GPUs (A100, H100, Tesla-class) are passively cooled and report N/A for fan speed; on those systems you monitor chassis fans through IPMI or the BMC instead, and a “missing” fan reading is normal.
What this means
The fan reading in nvidia-smi is a percentage of the card’s maximum rated fan speed, and per NVIDIA’s documentation it is the intended speed, not a measured RPM. Two consequences:
- A reported 0% with a hot GPU strongly suggests the fan never started, but you confirm it by looking at the card or listening to it, not by trusting the number.
- A reported non-zero value does not prove the fan is actually turning. On multi-fan cards the reading is typically an aggregate, so one dead fan out of three may not move the number at all.
The failure itself is simple: no airflow across the heatsink, die temperature climbs, and the GPU protects itself through the standard thermal cascade. First SW thermal slowdown at the max operating temperature (roughly 88-90C on consumer cards ), then HW thermal slowdown with an aggressive clock cut, then emergency shutdown. The workload does not crash; it just runs 2-10x slower until equilibrium, which is why a dead fan often surfaces as a performance complaint before anyone looks at temperatures. See thermal throttling in the GPU mental model for the full cascade.
The traps:
- Zero-RPM idle mode. Most modern consumer and workstation cards keep fans fully stopped below roughly 50-60C. A GPU idling at 40C with
Fan: 0%is healthy. This is the most common false alarm. - Passively cooled cards. Datacenter GPUs report
N/A, not 0%. Do not alert onN/A. - Multi-fan cards. Two or three fans, one aggregate reading. A single dead fan can hide behind the working ones while the card slowly heat-soaks.
- Driver fan-control faults. The fan column can show
ERR!when the driver loses communication with the fan controller. That is a driver/firmware state problem, not necessarily a dead motor.
flowchart TD
A[Fan reads 0%] --> B{GPU temperature}
B -->|Below ~50-60C, idle| C[Normal zero-RPM mode - no action]
B -->|Above 60C or under load| D{Fan audibly or visibly spinning?}
D -->|Yes| E[Reporting mismatch - check driver, per-fan data]
D -->|No| F{Fan column shows ERR!?}
F -->|Yes| G[Driver lost fan controller - reload driver or reboot]
F -->|No| H[Fan failure - throttle is imminent, plan replacement]Common causes
| Cause | What it looks like | First thing to check |
|---|---|---|
| Zero-RPM idle mode (normal) | 0% fan, temperature below ~50-60C, GPU idle | Apply load; fans should spin up as temperature crosses the threshold |
| Dead fan motor or failed fan header | 0% fan, temperature climbing under load, fan visibly stopped | Visual inspection of the card under load |
| Physically blocked fan (cable, debris, dust mat) | 0% or erratic fan, temperature climbing, sometimes audible ticking | Power down, inspect the fan blades and shroud |
Driver lost fan controller (ERR!) | ERR! in the fan column, often with odd P-state or 0% utilization | dmesg for NVRM/Xid errors around the time it started |
| One dead fan on a multi-fan card | Aggregate fan % looks plausible, temperature slowly rising at fixed load | Per-fan data via NVML, or physical inspection |
| Reporting mismatch (intended vs actual) | 0% reported but fans audibly spinning, or reverse | Compare the reading against physical observation |
| Wrong card class (passive datacenter GPU) | Fan reads N/A, not 0% | Confirm the model; monitor chassis fans via IPMI/BMC instead |
Quick checks
All read-only and safe to run on a production node.
# Fan speed and temperature together, per GPU
nvidia-smi --query-gpu=index,name,fan.speed,temperature.gpu --format=csv
# Full thermal picture: current temp vs the card's own thresholds
nvidia-smi -q -d TEMPERATURE
# Is the GPU already throttling for thermal reasons?
nvidia-smi --query-gpu=clocks_event_reasons.sw_thermal_slowdown,clocks_event_reasons.hw_thermal_slowdown --format=csv,noheader
# Current vs max clocks: how much performance is already lost
nvidia-smi --query-gpu=clocks.current.sm,clocks.max.sm --format=csv,noheader,nounits
# Driver-level errors that accompany a fan-controller fault
dmesg -T | grep -i "NVRM\|Xid" | tail -20
Interpreting what comes back:
- If
temperature.gpuis under ~50C and the GPU is idle, stop here. Zero-RPM mode is working as designed. - If
sw_thermal_slowdownorhw_thermal_slowdownreadsActive, the card is already protecting itself. Reduce load now; diagnosis continues after the card is safe. - The
T.Limit-style fields innvidia-smi -q -d TEMPERATUREoutput are margins (degrees remaining to a threshold), not absolute temperatures. ERR!in the fan column means the driver cannot talk to the fan controller. Pair it with whatever Xid or NVRM messages appeared indmesgat the same time.
How to diagnose it
Establish the baseline pair. Record
fan.speedandtemperature.gpuat idle. If the card is under 50-60C and idle, 0% is expected. Continue only if the GPU is warm or loaded.Apply or observe load. Watch the pair as temperature rises. A healthy fan curve starts moving the fan reading well before the card approaches its max operating temperature. Temperature climbing past ~65-70C with the fan still at 0% is the failure signature.
Physically verify. Look at the card or listen to the chassis. Because the reported value is the intended speed, physical observation is the tiebreaker. Spinning fans with a 0% reading means a reporting or control-path problem. Stopped fans with a hot card means hardware.
Check for
ERR!and driver errors. If the fan column showsERR!or other fields look wrong (odd P-state, 0% utilization with work queued), checkdmesgfor Xid events. This pattern points at the driver or fan controller firmware, and recovery usually means a driver reload or reboot rather than new hardware. Coordinate the reload: unloading the NVIDIA kernel modules requires no processes holding the GPU, and it kills running CUDA contexts.Rule out partial failure on multi-fan cards. If the aggregate reading looks fine but one card runs hotter than its siblings under identical load, suspect one dead fan.
nvidia-smiexposes a single aggregate percentage; per-fan speeds require the NVML API (nvmlDeviceGetFanSpeed_v2with a fan index), and support varies by card. Without per-fan data, physical inspection or a vendor diagnostic tool is the reliable check.Decide: fan fault or capacity fault. Fan at 0% plus rising temperature is a fan fault. Fan at 100% plus rising temperature is a different problem: blocked airflow, dust, failed thermal paste, or ambient/HVAC trouble. If one GPU in a multi-GPU box is hot, it is local to that card. If all GPUs are hot, look at the environment, not the fans.
Metrics and signals to monitor
| Signal | Why it matters | Warning sign |
|---|---|---|
fan.speed | The direct reading | 0% with temperature above idle range; 100% sustained |
temperature.gpu | Confirms whether 0% fan is dangerous | Approaching the card’s max operating temp |
clocks_event_reasons.sw_thermal_slowdown / hw_thermal_slowdown | Proof the fan problem is now a performance problem | Active during production compute |
clocks.current.sm vs clocks.max.sm | Quantifies performance already lost | Large gap under load with thermal reasons active |
| Fan speed at fixed workload over weeks | Bearing degradation shows up here first | Speed needed for the same load creeping upward |
Xid / NVRM errors in dmesg | Separates fan hardware failure from driver fan-control faults | Errors coinciding with ERR! in the fan column |
| Chassis fan speeds via IPMI/BMC | The actual cooling signal on passively cooled datacenter GPUs | Any chassis fan at 0 RPM |
The last row matters: on datacenter hardware the GPU fan field is N/A by design. If your monitoring treats N/A as an error, you will page on healthy A100s. The cooling signal for those systems lives in the BMC.
Fixes
Zero-RPM idle mode
Nothing to fix. If the false alarm came from monitoring, gate the alert: fan at 0% only matters when temperature is above the card’s zero-RPM range or the GPU is under load. Alerting on raw 0% without the temperature condition guarantees noise.
Dead or blocked fan
Clear obstructions first (cables are the classic culprit), then replace the fan or the card. Fan replacements on workstation cards are often possible without a full RMA, but that depends on vendor warranty terms. Until the fan is back, treat the card as unavailable for production load: it will throttle hard and eventually hit shutdown temperature. Do not keep running load on it and hope.
Driver lost the fan controller (ERR!)
This is a software-state fault. Re-running nvidia-smi or restarting applications will not clear it; recovery generally requires reloading the driver or rebooting the node. Drain workloads first. If the same card repeatedly lands in ERR! after clean reloads, suspect the card’s fan controller hardware and plan replacement.
One dead fan on a multi-fan card
The card may survive on the remaining fans at reduced load, sometimes for a long time. That is a trap: it runs hot, ages the thermal interface material, and sits one fan away from real failure. Replace it during the next maintenance window rather than waiting for the second fan to go.
Bearing degradation
Rising fan speed for the same workload over weeks is the early warning: the fan is working harder to move the same air. No immediate action, but schedule replacement and watch the temperature baseline alongside it, since degraded fans and dried thermal paste tend to travel together.
Prevention
- Alert on the pair, not the fan alone. Fan 0% AND
temperature.gpuabove the idle range is the page-worthy condition. Fan 0% alone is noise because of zero-RPM modes. - Classify your fleet by cooling type. Air-cooled consumer/workstation cards get fan-speed monitoring. Passively cooled datacenter cards get IPMI/BMC chassis-fan monitoring. Never alert on
N/A. - Trend fan speed against fixed workload. A weekly comparison at a known load catches bearing wear months before failure.
- Watch throttle reasons, not just temperature.
hw_thermal_slowdownactive is the confirmed impact signal; temperature alone over- and under-fires. - Include fans in burn-in. New cards and post-maintenance cards should get a load test that confirms the fan curve actually responds before the node rejoins production.
- Multi-fan cards: inspect during maintenance. Since the aggregate reading hides single-fan failures, periodic physical inspection is the cheap safety net.
How Netdata helps
- Netdata collects
fan.speed,temperature.gpu, clock throttle reasons, and power draw per GPU at per-second resolution, so the fan-vs-temperature divergence this article is about is visible as one correlated view rather than two separate queries. - A fan stuck at 0% while temperature climbs shows up as an obvious curve split; ML-based anomaly detection flags the temperature trajectory before it reaches throttle thresholds.
- Throttle reason metrics (
sw_thermal_slowdown,hw_thermal_slowdown) confirm whether a cooling problem has become a performance problem, which is the escalation decision. - Historical fan-speed data makes bearing degradation visible: speed for a given workload trending up over weeks stands out in long-range charts.
- Because Netdata also monitors the host, a fan failure can be correlated with ambient temperature, other GPUs in the same chassis, and system thermal sensors to separate a local fan fault from an environmental one.
Related guides
- NVIDIA GPU monitoring checklist: the signals every production GPU fleet needs
- How an NVIDIA GPU actually works in production: a mental model for operators
- NVIDIA GPU monitoring maturity model: from survival to expert
- NVIDIA-SMI has failed because it couldn’t communicate with the NVIDIA driver
- NVIDIA GPU HBM progressive failure: from single-bit errors to a dead GPU






