My computer is overheating

Every computer runs hot — that's not a defect, it's physics. A processor converts electrical power into two things: the work you wanted, and heat, which is the majority share. The cooling system exists to move that heat out of the machine and into the room, and it does so through a chain: the chip hands heat to a heatsink, the heatsink hands it to moving air, the fan provides the movement, and the case and room provide the path. “Overheating” is the specific state where heat production outpaces that chain. The machine then starts paying for the difference, on a ladder: first it throttles (cuts the chip's speed to cut the heat — the “only slow under load” symptom), then, if that isn't enough, it shuts down (the protection trip), and over long periods of sustained near-limit operation, components age faster than they would in the comfortable range. Understanding that ladder is the key to the rest of this page: each rung is a message, not just an annoyance.

Which brings the honest correction to the most common question — “what temperature is too hot?” There is no universal number. Safe and throttle temperatures depend on the chip's design, the cooling attached to it, and the room it sits in; a modest laptop chip and a high-end desktop CPU have different limits, and the same chip runs differently on a stock cooler than on a good aftermarket one. What is universal is the behavior: every chip throttles near its documented limit, and every chip's documentation states what that limit is. So the working definition on this page is behavioral, not numerical: your machine is overheating if it throttles, shuts down, or runs meaningfully hotter than its own past baseline under the same workload and room — and a machine that is warm but stable, quiet, and fast is probably fine at exactly the number it's showing. The temperature section covers how to read numbers within that frame, including rough bands that are useful as context but never as verdicts.

Two questions structure everything that follows, and both are answerable on this page. The first: is it hot for its hardware? — which is answered by behavior (throttling, shutdowns) and by your own baseline, not by comparing against strangers' screenshots. The second: is it getting worse? — because the dominant real-world cause of “my computer used to be fine” is slow accumulation (dust, aging paste, a tired bearing), and “worse over time” is that accumulation's signature. A sudden change points elsewhere (a moved machine, a new workload, a failed fan); a slow creep points at the chain degrading. Note which pattern you have before you start — it decides whether you're cleaning a clog, replacing a part, or chasing a setting.

The signs cluster into four families, and each family points at a different part of the story. Heat you can feel: a laptop's bottom or vent area running hot, a desktop's case side or top warm to the touch, the keyboard region of a laptop baking your palms. Touch is a crude instrument — case materials, paint, and your own hand's temperature all distort it — but a surface that makes you move your hand away is past “warm” into “the cooling isn't keeping up.” Fan behavior: fans at high speed all the time, fans that ramp to maximum the moment a real load starts, or — the version that worries more — a machine that's hot with no fan noise where there should be some. Performance behavior: the signature of throttling is slowness that appears under sustained load and eases when the machine cools — a game that runs fine for ten minutes and stutters by the twentieth. System behavior: shutdowns under load, restarts, and (less specifically) crashes that correlate with long, heavy sessions.

The pattern matters more than any single sign, and there are three patterns worth naming. Constant: hot most of the time, in a warm room, doing normal things — usually the ambient plus the machine's normal design, and the first question is whether this is simply what this machine does (the baseline question). Under load: fine at idle, climbing during real work — the expected shape of heat, where the question is how high it climbs and what behavior follows. Worsening over time: the same room, the same work, and each month a little hotter — the accumulation signature, and the one that most often ends at a clean or a replaced component. When you describe the problem to yourself (or to a technician later), the pattern is the sentence that carries the most information: “hot at idle and getting worse” is a nearly complete diagnosis on its own.

Finally, heat has a location, and the location is evidence — with the honest caveat that layouts vary by machine. On many laptops, the bottom near the hinge runs hotter than the center (graphics side on a lot of models, CPU side on others — yours may differ); a hot spot with no fan noise or airflow nearby is more interesting than a hot vent with a loud fan, because it suggests heat that isn't being moved rather than heat that's being moved hard. On a desktop, the top-rear exhaust being warm is normal (that's where the hot air leaves); a case side that's hot over the graphics card under load is also normal; the suspicious cases are a hot CPU area with the case fans barely running, or a machine whose hottest spot is somewhere with no fan and no vent at all. You don't need to decode the location precisely — you need to notice it, because “where is it hottest, and is anything moving air there?” is a question the no-special-hardware diagnosis builds on directly.

Heat doesn't disappear — it moves, and a computer's cooling system is a pipeline with exactly one job: move the chip's heat to the room. The pipeline has four links, and the whole troubleshooting method on this page is an inspection of them. The chip is the source — it makes more heat the harder it works, and its output is set by the workload, the power settings, and (on some machines) an overclock. The heatsink is the interface — a metal block (often with fins) that the chip's heat conducts into, made effective by the thin thermal interface between them; this link fails through mount pressure loss and paste aging. The fan is the mover — it pushes air across the fins so the heat has somewhere to go; it fails through bearing wear, power/connection problems, and control (a curve that keeps it lazy). The path is everything around the fan — case airflow, vents, filters, placement, and the room's air temperature; it fails through dust, blockages, recirculation, and simple bad location. A machine overheats when the total resistance of those four links exceeds what the workload produces — and because each link degrades independently, the same symptom (a hot machine) has four different first fixes.

The chain framing explains the two things people most often get wrong about overheating. The first: why a “sudden” heat problem is usually not sudden. The links that fail most often in the field — dust in the fins, dust on the filter, paste drying, a bearing wearing — all fail slowly. A machine that “started overheating last month” was probably running 10–15 degrees hotter than its first-year baseline six months ago; the problem had a duration, and the duration is the clue that points at accumulation rather than a fault. The second: why adding a fan doesn't always help. A fan only moves air if there's air to move and somewhere for it to go — a case with no intake path, a laptop with its intake blocked by a blanket, or a fin stack packed with dust will all get hotter or noisier from more fan, because the constraint wasn't fan count. This is why the fixes on this page are ordered by link (source → interface → mover → path) and why the diagnostic tree asks “is there real airflow?” before it recommends anything.

One more consequence of the chain model, because it changes how you should think about your own machine: the chain has a weakest link, and the weakest link sets the machine's real limit, not its best component. A superb cooler on a dust-clogged case is a clogged case; a spotless machine in a 30-degree room in August is an August-room machine. That's why two of the cheapest checks on this page — the placement and airflow review and the ambient test — sit so high in the order: they test the links that cost nothing to check and nothing to fix, and they explain the “hot at home, fine at the office” cases that otherwise baffle people. The rest of the page is the chain, link by link, with the safe checks for each.

When the machine is hot now, the goal isn't a diagnosis — it's lowering the heat load and giving the cooling a chance, without doing anything irreversible. The moves, in order: reduce the load (close the game, the render, the dozen browser tabs — heat follows work, and cutting the work is the fastest heat reduction available); improve the path (a laptop onto a hard, flat surface with the vents clear; a desktop out of a cupboard or away from the wall it's breathing against); and let it recover (a pause of several minutes at light load, or a full shutdown if it's at the “move your hand away” level — a shutdown is not a failure, it's the machine asking for a break, and granting one is free). The table below maps the specific situations to the move, the reason, and where to go next. The one situation that skips all of this: a burning smell, smoke, or a history of liquid — that's power off, unplug, and the professional section, full stop.

Two notes on doing this well. First, the immediate moves are also your first diagnosis: if moving the laptop to a desk and closing the render brings the temperature and the noise down within minutes, you've identified the constraint (placement plus load) without opening anything — which is the common and the good outcome. If the machine is hot at idle on a desk in a cool room with nothing running, the immediate moves won't help, and that's the signal to go straight to the idle-heat section, because that combination means a link in the chain is broken rather than overloaded. Second, keep a five-minute note of what you see (how hot, when, what it was doing, the room) — not for you to analyze, but because that note is exactly the information the professional section asks for later, and it's much easier to write down now than to reconstruct from memory a week from now.

The protection ladder has three rungs, and reading which one your machine is on is more useful than the temperature number. Throttling is the first: the firmware cuts the chip's clock speed to shed heat, and the visible symptom is performance — a machine that's fine at the start of a long session and degraded by the end, or “slow” that only appears under load. Throttling is the machine working as designed to protect itself; the problem it signals is that the cooling can't keep the chip in its comfortable range under your workload. The thermal shutdown is the second: the chip (or the board's monitoring) decides the limit is being crossed too fast or too far, and cuts power. It's dramatic, it's scary, and it's still the protection doing its job — but it's also the machine telling you the gap between heat production and heat removal has grown from uncomfortable to unsafe. Freezes and crashes are the ambiguous rung: a freeze under load on a hot machine can be heat outrunning the protection (the chip misbehaving before the trip fires), or it can be an entirely different cause — memory, a driver, the operating system — wearing the same clothes. Heat is a candidate for a load-correlated freeze, not a proof of one.

How to confirm the heat connection, honestly: the pattern does the work. A thermal cause has a shape — it happens under sustained load, it's better when the machine is cold (first session of the day, after a full cooldown), it's worse in a warm room, and it worsens over weeks if the cause is accumulation. A machine that shuts down in a cool room at modest load, or that shuts down at random times unrelated to work, is asking for the other explanations — and the honest note is that shutdowns have non-thermal causes too (power delivery, a failing component), which is why this page treats “shutdown under sustained load, better when cold” as the thermal fingerprint rather than assuming every shutdown is heat. The temperature section's logging method is the confirmation: a reading that's at or past the throttle point at the moment of the slowdown or shutdown makes it a finding. And one cross-link that saves people a loop: if the machine has shut down and now won't restart normally, that conversation has moved to the power side — the won't-turn-on guide is the right next read, with “it was running hot” as the first line of history.

What each rung changes in your plan. On the throttling rung, the goal is restoring headroom, and the levers are in two families — reduce the heat produced (workload settings, power limits, the software section's levers) or improve the heat removed (the chain: dust, airflow, fans, paste) — and the durable answer is always the second family, because settings are a bridge, not a fix, for a machine that was bought to do the work you're doing. On the shutdown rung, the same two families apply but the tolerance is lower — a machine that's tripping protection is one where repeated attempts have a cost, so the cheap checks (placement, dust, the ambient test) come first and the repeated stress-tests come last, if at all. And on the freeze rung, the discipline is to not over-attribute: run the thermal checks, and if the machine is cool and stable when the freezes happen, the heat story is closed and the crash-side guides are the real destination.

Free, well-known monitoring utilities show the CPU and GPU temperatures in real time — any reputable one does, and the choice matters less than the method. The method: read two numbers, not one. The idle number — the machine at its desktop, nothing heavy running, a few minutes in — and the load number — the same machine in the workload that's been causing the problem (the game, the render), read while it's happening. Log both, with the date, the workload, and (this is the part everyone skips) the approximate room temperature. Do it once now, and again in a few weeks, and you have the two instruments this page keeps referring to: the delta (how much higher load is than idle — the cooling chain's job is to keep that delta manageable) and the trend (the same two numbers over time — the accumulation signature shows up here long before it shows up as a shutdown). A single screenshot of a number, without the workload, the room, or the past, is not a diagnosis; it's a mood.

Now the interpretation, which is where the honesty lives. The bands in the table are context, not law: some cool designs idle in the 30s and hold the 70s under load; some hot designs by nature run a decade higher; a laptop's numbers and a desktop's aren't comparable; and a warm August room adds to every single one of them. So the number earns its keep in three comparisons only — against your own baseline (the same machine, the same room, six weeks ago), against the machine's behavior (is it throttling or shutting down at this number? that's the real line), and against the documented limit for your chip (the manufacturer's specification is the reference, not a forum thread). A practical reading rule: if the load number is stable, the machine is fast, and the trend is flat — you're fine, whatever the digits. If the load number is creeping toward the throttle point across weeks, or the machine is throttling at a number it used to hold easily — that's the overheating this page is about, and the trend, not the snapshot, is what you bring to the fixes. And the ambient caveat, stated once for every table on this page: the room's temperature adds directly to the chip's — a 30-degree room in summer is a different machine than the same box in a 20-degree room, and “it's only hot in July” may be the whole story (the ambient test proves it either way).

You don't need a thermal camera or a multimeter to run most of this diagnosis — the machine has been reporting its state the whole time, in heat, air, sound, and behavior. The touch-and-air pass, done deliberately: with the machine under its usual load, briefly feel the exhaust area (the top-rear of a desktop, the vent side/rear of a laptop) — is it hot, and is air actually coming out? Air plus heat is a working chain under load; heat without air is the blockage-or-dead-fan branch; neither heat nor air at idle is normal. The fan-ear pass: is the fan making progress (a steady whoosh that changes with load), or is it making a character (grind, whir, rattle) that doesn't change with load — the first is working, the second is the bearing story. The hotspot pass from the signs section: where is it hottest, and is anything moving air there? Those three passes, five minutes, no tools, and they cover a large share of the decision tree.

Then the behavior tests, which are the no-equipment equivalents of a load test. The cooldown test: shut the machine down fully for thirty minutes (a full power-off, not sleep — the components need to actually cool), then repeat the workload that's been causing trouble. If the first run after a cooldown is clearly better than a run after the machine's been going all day, heat is in the loop and the chain is running out of headroom. The ambient test: move the machine to a genuinely cooler spot for the same workload — a window fan aimed at a desktop case, a laptop by an open window on a hard surface — and compare. A meaningful improvement says the room was a real part of the equation (and that the machine may be fine, just location- and season-limited); no improvement says the constraint is inside the machine, where the chain sections apply. The time-to-slowdown test: for throttling specifically, the clock is the instrument — how many minutes into the same game or render until the stutter or slowdown appears? That number, tracked across days, is the single clearest trend line available without any software at all, and “twenty minutes last week, eight today” is a diagnosis with a date on it.

The output of this section is a pattern log, and it's worth being specific about why: five lines — date, workload, what happened (temps if you have them, or the time-to-slowdown, or “shut down at minute ~15”), the room (roughly), and what changed since last time — does more for the eventual diagnosis than any single reading, because thermal problems are trend problems and a log is a trend machine. It's also, as the professional section notes, the intake form: a technician who gets “hot at idle and under load, worse since spring, shutdowns in the last two weeks, room's been hot” can start at the likely links instead of re-running the observation pass you've already done. If the no-tools pass and the behavior tests point at the same link (they usually do — dust, airflow, or a fan), go to that section; if they point at different places, the temperature logging is the tiebreaker, because it's the one method on this page that measures rather than infers.

Heat follows work, and a processor at full tilt makes dramatically more heat than one idling — which means “overheating” with nothing apparently open is often a machine that's very much not idle. The check takes a minute: Task Manager on Windows (the Processes view, sorted by CPU), Activity Monitor on macOS (the CPU tab), and a similar view on Linux. You're looking for the process that's high while you're doing nothing — the constant user, not the spike that comes and goes with your own clicks. The usual suspects, in rough order of frequency: update and indexing work (an operating-system update settling in, a search index being built, an antivirus scan) — real work, temporary, and the correct response is usually to let it finish and check again tomorrow; a misbehaving application (a sync client spinning, a browser tab or extension gone rogue, a game launcher doing something in the background) — end it, restart it cleanly, and see if the CPU (and the heat) follows it down; and the browser itself, which with enough tabs and extensions becomes a legitimate heavy workload that many people don't count as “using the computer.”

The suspect that deserves its own paragraph: malware, including cryptominers. The pattern that separates it from the benign list is specific — high CPU when you're demonstrably not using the machine (overnight, at work, on battery with everything closed), battery or runtime that drains faster than it used to, and processes you don't recognize. The honest line: a full scan with your current, updated antivirus (plus a second-opinion scanner if the pattern is strong) is the check, and a scan finding nothing doesn't fully exonerate — but neither does a high CPU prove an infection, which is why this is “run the scan and compare the pattern,” not “you have malware.” A miner, if present, is also the explanation for a machine that “overheats all the time for no reason,” and removing it is the entire fix — the one case on this page where the software is the whole story and the cooling chain was innocent all along.

Two frames that keep this section from overreaching. First: a high CPU with normal temperatures is not a thermal problem. The chip is working hard, the cooling is keeping up, and the machine is doing exactly what a computer does — the heat only becomes the story when the cooling can't keep up, which is the delta-and-trend question. Background load that you can see, name, and control (the update, the scan, the render) is work you chose or accepted; the thermal work starts when the temperatures follow that load into throttling territory. Second: this check comes first in the idle-heat procedure (the idle section), because it's the cheapest test on the page — a minute of looking, fully reversible, no opening, no air, no parts — and it clears an entire category of “mystery heat” before the hardware sections are consulted. If the background pass comes up clean and the machine is still hot at idle, that's a genuinely useful negative result: the heat is coming from the cooling chain's failure, not from hidden work, and the fan and dust sections become the primary suspects.

Dust is the most common real-world cause of “it used to be fine,” and the mechanism is simple once you see it: dust is an insulator, and it settles exactly where the cooling chain needs to work — on the heatsink fins (where it builds a blanket between the metal and the air), on the fans (where it unbalances them and slows them), and on the filters and vents (where it chokes the airflow before it starts). The result is a slow, monotonic loss of cooling: the same machine, the same room, the same work, and each month the numbers a little higher, until the day the loss crosses into throttling and the machine announces itself. That progression is the signature — “worse over time” is dust's fingerprint — and it's also why dust is the most fixable cause on the page: nothing is broken, something is accumulated, and accumulation can be removed. Pets, carpet, a dusty room, and a case that intakes from the floor all shorten the timeline; a clean, hard-floored room lengthens it.

Checking for it, without opening anything: look into the vents (visible dust at the edges of a vent or a filter is the obvious case; the interesting case is the airflow test — at the exhaust, under load, is air coming out with any force, or is it a weak trickle?), note the machine's age since its last clean (if “I don't remember” is the honest answer, that's the answer), and consider the environment (the pets-and-carpet question). If any of those point at dust, the fix is the cleaning procedure — external vents always, the desktop interior if you're comfortable, the fan-held rule throughout — and the expected result is worth stating because it's the best cost/benefit on the page: a proper clean often restores a machine to near its original thermal baseline, and the improvement is visible in the logged numbers within a day or two of normal use. The prevention side is the placement section (intake location, filters) plus the maintenance rhythm — dust doesn't come back all at once, which is why a rhythm beats a heroic annual deep-clean in most environments.

One honest boundary, because it shapes the advice: dust alone rarely causes a catastrophic failure — it's a degradation that ends in throttling, which is why it's so often caught in time and why a “dusty machine” is almost always a “fixable machine.” The cases where dust stops being the whole story are the ones where the trend doesn't improve after a thorough clean (then the next links — the fan, the paste, the cooler — are in the loop too), and the cases where the machine was never clean to begin with (a machine that bought hot and has always run hot may be a design-and-room story rather than an accumulation one — the ambient test separates the two). And the laptop caveat that runs through this whole group: a laptop's dust problem is real and its vents can be cleaned from the outside, but the fins inside a laptop are professional territory for most people, which is why the laptop section draws that line explicitly.

Airflow is the link people underestimate because it's not a component — it's a relationship between the machine, its enclosure, and its location. The rule is simple to state and easy to violate: intakes need cool air, exhausts need an escape, and the air between them needs a path. Break any of the three and the fans work harder (louder, and wearing faster) for less cooling, and the machine runs hotter than the same machine in a better spot. The placement failures, in the order they're most common: a laptop on a blanket, duvet, or bed — the soft surface covers the intake (usually the bottom) and the whole cooling chain now has to move heat through fabric; a desktop in a closed cabinet or cupboard — the exhaust dumps hot air into an enclosed volume that the intake then re-breathes, so the machine is literally cooling itself with its own exhaust; a desktop pressed against a wall with its intake or exhaust facing it; and the seasonal version of all of these — a machine in a room that runs 30 degrees in summer is a different machine than the same box in 20, and the ambient test is how you find out how much of your problem is the room.

The fixes cost nothing and are fully reversible, which is why this section sits before the parts. Laptop: a hard, flat surface, always — a desk, a table, a laptop stand; the vents (side and/or rear on most models, bottom intake on many) unobstructed; and elevation genuinely helps, because a stand or even a book-propped rear lifts the bottom intake off the surface and gives the hot air under the machine room to leave. A cooling pad is the same idea with a fan — it works when the bottom intake is the constraint (the laptop runs measurably cooler elevated-and-fanned than flat), and it doesn't work when the machine's internal path is clogged (a pad can't clear dust from inside); treat it as placement with extra steps. Desktop: clearance at the wall (the case's exhaust needs the room, not the plaster), out of the cupboard or with the door open while it's working, the intake side facing open air, and the cable management checked — a bundle of cables across an intake is a blockage with a plug in it. The test for all of it is the same five-minute one: move the machine to its best possible spot, run the usual workload, and compare the logged numbers — a meaningful improvement means the location was a real part of the equation, and “hot at home, fine at the office” cases usually end right here, because home and office are different rooms in different spots.

The deeper version of this section — the desktop case's internal airflow — has its own article in the hardware group (desktop case airflow), because a case is an airflow machine with intakes, exhausts, and a path to design; this section is the room-and-spot layer, and the two are the same law at two scales. The shared failure mode worth naming: recirculation — hot exhaust air finding its way back to an intake — happens at both scales (a case in a cupboard; a case whose rear exhaust points at its own side intake) and it has the same signature: fans working hard, numbers higher than the hardware should produce, and improvement the moment the escape route opens. If the placement pass improves things but not enough, the machine has a location problem and a chain problem — which is the normal case for a machine that's been in a bad spot for years, because bad spots are where dust settles thickest. Fix the spot, then run the dust check; the two fixes compound.

The fan is the link that makes the whole chain active — a perfect heatsink with no air moving across it is a warm brick — and it fails in four distinguishable ways. Not spinning at all: the power or connection is the first question (a fan connector that's worked loose is the desktop version — the same “bumped connector” logic as the power connectors in the won't-turn-on guide — and the classic BIOS message “CPU fan error” at startup is the board telling you its CPU fan header sees nothing); on a laptop, a silent fan with a hot bottom is the same finding at a scale you can't service yourself. Spinning slowly: usually a mechanical drag — dust packed into the blades, or a bearing that's starting — and the check is the same airflow test (a clogged fan spins down because it's fighting resistance). Spinning only at maximum: a control problem rather than a hardware one — a fan curve stuck at its ceiling, or a machine that's so hot it's legitimately at 100% all the time (which is the accumulation story wearing a fan's clothes). Noisy: the bearing story — a steady loud is working hard; a grind, whir, rattle, or a speed that wobbles with no change in load is a bearing failing, and bearings don't get better — they get louder, then they stop.

The checks, by machine. Desktop: with the case open and the machine running (briefly, hands clear of the blades — the standard caution for any fan work), which fans are actually turning? The CPU cooler's fan, the GPU's fans (note: many GPU fans are curve-controlled and legitimately idle when the card is cool — check them under load), and the case fans. A connector that's loose goes back in; a fan that's clogged goes to the cleaning procedure; a fan that's mechanically noisy is a replacement candidate. Laptop: the fan is deeper, so the instruments are the sound (the character, not just the volume — the signs section's fan-ear pass) and the airflow at the vents (no air with the machine hot is the dead-or-stuck finding), plus the software layer — on many laptops the fan policy lives in vendor control software rather than the BIOS, and a stuck or mis-set profile can read as a hardware fault (the software section covers the safe checks there; the general rule is to trust the vendor's tool and skip the third-party “fan booster” utilities, which rarely help and occasionally make things worse).

Replacement, and the line. A fan is one of the cheapest, most standard parts in computing — a desktop case fan is a straightforward swap for anyone comfortable with the case, and a CPU cooler's fan is often replaceable on its own. The honest skill line: desktop, usually fine as DIY; a laptop's internal fan, an AIO pump, or anything under warranty, is where most people should stop and call it in (the professional section), because laptop service is a different craft and the warranty question is real. And the decision rule for the noisy fan, stated plainly: replace a fan on its noise, not on a schedule — a steady-loud fan is doing its job and deserves to keep working; a grinding or wobbling one is on the clock, and the machine's thermal headroom is quietly borrowing time from that bearing. The one combination that changes the urgency entirely: a fan that isn't spinning on a machine that's hot now — that's the immediate-actions situation (reduce load, cool it down) followed by the fan finding, not a “look into it this weekend” item.

Thermal paste (the thermal interface material between the chip and the cooler) does a deceptively important job: the two metal surfaces that look flat are microscopically full of peaks and valleys, and the paste fills the valleys so heat can conduct across. Get that interface wrong — too little, too much, dried out, or a cooler that's lost its pressure — and the chip's heat has a bad road out, and the whole machine runs hotter with every other link doing its job. It ages: over years, most pastes dry and lose effectiveness, which is one of the slow causes behind a multi-year-old machine's creeping baseline. And it's disturbed by work: any cooler removal (a clean, an upgrade, a “while I was in there”) is a paste event, because the old interface can't simply be put back — it must be cleaned and reapplied, which is the step that gets skipped and later wondered about. The signature that points here specifically: a machine that was fine before a service and warmer after (the reapplication or the mount went wrong), or a machine several years old with a slow creep and everything else on the chain checked out.

When to reapply, honestly: always after a cooler removal (non-negotiable — running a chip on a broken interface is running it hot by design); on a machine several years old that has grown warmer with dust, airflow, fans, and settings all exonerated (the paste is the remaining slow link, and it's the reasonable next test); and not on a schedule by itself — paste is not an oil change, and a machine with no thermal complaint doesn't need a paste job as prevention. The procedure for the people it's appropriate for (a desktop with a tower cooler, comfortable with the case, the machine unplugged and discharged): remove the cooler, clean the old paste off both surfaces with isopropyl alcohol and a lint-free cloth (the “both surfaces” is the step the mistakes list exists for), a small amount of new paste — a pea-sized dot at the center is the common guidance, and the mount's pressure spreads it — and remount to even pressure, following the mount's own instructions (the tightening pattern matters more than the force; cross-threading a mount or over-torquing it are the two ways this goes badly). The warnings, stated as the section states them: the mount types vary (the manual is the reference — don't assume your cooler's mechanism matches the last one you saw), the work is unplugged-and-discharged case work, and the moment the machine in question is a laptop or an AIO, the honest answer for most readers is the professional column, because laptops use pads as well as paste and get them wrong in ways that are expensive to fix.

What the result should tell you. A paste job is a test with a clear readout: relog the baseline after a day or two, and compare. A meaningful drop (the load number back toward the machine's old range) says the interface was a real part of the story — fix complete, and the machine's on a new multi-year clock. No change says the paste wasn't it, and the suspicion moves to the remaining links — the cooler's match and mount, the airflow the cooler is trying to use, or (on a machine that's been hot for a long time) the failure-signs conversation. One framing that keeps this section in proportion: paste is a real cause in a minority of cases, which is exactly why it sits after dust and airflow in the order — the accumulation that's everywhere (dust) gets tested before the interface that's sometimes wrong (paste). And the corollary for anyone who's had a service done: if a machine got warmer after a technician opened it, the paste-and-mount job is the first question to ask about that visit, because a service is the one event where the interface is guaranteed to have been touched.

The CPU cooler is the heatsink-and-fan unit on the processor, and it has three failure families that the paste section doesn't cover. The mount: the cooler has to press evenly and firmly against the chip, and that pressure is a thing that can be lost — a mount that's loosened over years, a mount that was reassembled wrong after a service (the “warmer since the repair” signature, shared with the paste), or an aftermarket mount that wasn't matched to the socket. The check is visual and tactile with the machine unplugged: the cooler should feel solidly seated, and the mounting hardware should match the pattern its instructions call for. The match: coolers are sized against the chip's heat output, and a high-output chip under a small stock cooler doing sustained work is a mismatch that shows up exactly when the workload is sustained (the workload section's territory) — a gaming or editing machine whose cooler was adequate for the machine it shipped in but not for the work it's doing now is a real and common story, and the answer there is an upgrade, honestly labeled as one. The liquid cooler (AIO), where fitted: the failure that defines the category is the pump — the fans on an AIO can be spinning perfectly while the loop inside has stopped circulating, and the signature is a hot CPU with a machine that looks like it's cooling fine. The safe checks are external: is the pump powered (it has its own connector and, on some boards, its own failure indicator), does the tube show a temperature difference that suggests flow, and has the pump's hum changed? The honest limit: an AIO's internals are not user-serviceable — a dead pump is a replace-the-unit event, and a leak (dampness, residue, any sign of fluid where fluid shouldn't be) is an immediate power-off-and-stop that goes straight to the professional section.

The airflow question the cooler has to win. A cooler is only as good as the air that crosses its fins, which means the cooler's fans (direction: pushing into the fins and out of the case, per the cooler's design) and the case's path (the case airflow section) are part of the cooler's performance, not separate from it. A perfectly mounted, fresh-pasted cooler in a case with no airflow is a radiator with no wind — and this is the case where the fix people reach for (a bigger cooler) is sometimes the wrong one, because the constraint was the path. The order: mount and paste first (cheap, quick), then the airflow the cooler depends on, and only then the cooler's size — because a bigger cooler in a starved case improves the numbers by less than people expect, and the path fix improves them for every component at once. The upgrade decision, stated as a decision: a sustained-workload machine (the rendering/editing case) that throttles with mount, paste, dust, and path all in order has a genuine cooler-capacity problem, and a larger or better cooler is the correct, honest answer — a part, with a price, that buys back the headroom the workload needs. For a machine whose work is bursty (normal use, casual gaming), the same finding is rarer, and it's worth re-running the cheap checks before the purchase, because a “capacity” diagnosis on a light-workload machine usually means a link upstream was missed.

What to bring to the cooler question, and what it rules out. The cooler section is where three earlier findings converge: the trend (creeping numbers point at the slow links — paste, mount, dust), the fan findings (the cooler's fan is the first fan to check, and its behavior is data), and the behavior (a machine that throttles at exactly the point its old self held is a headroom story). If the cooler work — mount, paste, the cooler's fans, the path — leaves the numbers where they were, the remaining explanations are the chip's settings (the power and clock levers, including an overclock that's been added at some point and forgotten) and the failure side (the failure-signs section, where a machine that runs hot despite a verified-good cooling chain starts to look like a machine whose heat production has changed). That last distinction — heat removed vs. heat produced — is the cooler section's boundary, and it's the reason the page's final group exists: some “overheating” stories end at a part, and some end at a professional, and the cooler is usually where you find out which.

A graphics card is a cooling system in a box — its own heatsink, its own fans, often a vapor chamber — and it fails in the same four ways the CPU side does, with two differences that matter. The first difference is the localization trick, which is the reason GPU heat gets its own section: run a graphics-heavy workload (a game is the natural test) and read both temperatures — a hot GPU with a cool CPU says the problem is on the card's side of the house, and a hot CPU with a reasonable GPU points the other way. That one comparison splits the machine's thermal story in half, and it's the single most useful diagnostic move on this page after the idle/load split. The second difference is the serviceability line: the card's external side (its fans' dust, its airflow in the case) is fair game for the same checks as everything else; the card's internals (its paste, its thermal pads) are where the line sits — repasting a GPU is a skilled job on a warranty-bearing component, and for most readers it's the professional column, full stop.

The checks, in order. The card's own dust: visible from the side of the case — dust packed into the card's fin stack is the GPU equivalent of the heatsink dust, and the cleaning procedure covers the safe pass (the card in place, air from the side, the fans held). The card's fans: do they spin under a graphics load? The honest note again — many card fans are curve-controlled and sit idle when the card is cool, which is by design (a cool card is a quiet card); the test is under load, where a card running hot with silent fans is a control or a bearing finding. The airflow to the card: the card intakes from the case, and a case with no intake air reaching it starves the GPU exactly as it starves everything else — the case airflow section applies directly, and a card that runs cooler with the case door open is a case-airflow story, not a card story. The card's settings: driver updates can change a card's power and fan behavior (the “it got hotter after the update” case — the driver is a legitimate suspect and a rollback is the test, per the software section), and the vendor tools offer the same levers as the CPU side — a power limit, a fan curve, and (on many cards) an undervolt, which for a GPU is often the single best heat-per-performance move available to a user, done in small steps and fully reversible.

What the findings mean, and the honest end states. A GPU that runs hot with clean fins, working fans, and good case airflow is, in most cases, an aging card — its internal interface has done its years, and the options are the honest ones: accept the numbers (if the card isn't throttling or the machine isn't suffering, “hot but stable” is livable), apply the levers (the power limit or undervolt buy real headroom for little), or replace (a card at the end of its thermal life is a purchase decision, not a repair one — and a card that's throttling in the games it was bought for is the version where the conversation is worth having). The one warning that's specific to the GPU side: a card that's chronically hot is also a card whose fans are wearing chronically — the bearing story from the fan section applies to card fans exactly, and a card fan's grind is the replace-the-card-or-the-fan conversation, usually the card. And the cross-link that closes the loop: if the GPU's story is “the case isn't feeding it air,” the fix is the case airflow section, and if the machine's whole story is “everything's clean and it's still hot,” the next read is the failure-signs section — because at that point the question has quietly changed from “how do I cool this machine” to “is this machine's cooling, or its heat, failing?”

Laptops overheat more than desktops for a reason, and the reason is the design: desktop-class heat in a fraction of the volume, moved by smaller fans through shorter paths, in a case that isn't built for frequent opening. Two consequences follow. The first is that some heat is the design — a laptop's bottom and vent area being warm during real work is normal, and a laptop is not a failed machine because it's warm the way a desktop case is warm; the failures are the behaviors (throttling, shutdowns, heat at idle in a cool room) and the surfaces (hot enough to be uncomfortable or to damage what's under it). The second is that placement is a bigger lever on a laptop than on any desktop, because a laptop's intake is usually its bottom — which is the part that meets the blanket, the bed, the lap, and the closed bag — and covering it doesn't just reduce the cooling, it can remove most of it. The laptop's first rule is the one the airflow section states: a hard, flat surface, vents clear, always; and the elevation bonus (a stand, or the rear propped) genuinely helps, because it gives the bottom intake and the hot air under the machine a path.

The laptop-specific checks, in the order that respects the machine's serviceability. The vents (usually side and/or rear; the intake often under the keyboard and along the bottom edge): the external clean from the cleaning procedure — air at the vents, the fan held — is the laptop's version of the dust fix, and it's the one internal-adjacent task most owners can do safely. The fan, by its sound and the vent airflow (the fan section's instruments) — a laptop fan's bearing end-stage is the whir-and-wobble character, and its replacement is the professional column for most people. The control layer: many laptops put the fan policy in vendor software rather than the BIOS — check the vendor's tool for a stuck profile or a “quiet” mode that's fighting the workload, and skip the third-party fan utilities (the software section says why). The hard reset, for the laptop that's hot and behaving strangely (stuck states can pin fans and throttle limits): unplug, remove the battery where the design allows, hold the power button for fifteen to thirty seconds, reconnect, restart — the same procedure the won't-turn-on guide uses, applied here to a stuck thermal state. And the cooling pad, placed honestly: it adds airflow under the bottom, it helps when the bottom intake is the constraint, and it cannot clear what's inside — a pad-cooled clogged laptop is still a clogged laptop.

The line, stated the way the rest of the page states its lines: on a laptop, the owner's territory is the outside and the software — the surface, the vents from the outside, the control software, the workload levers (power, settings, the frame cap) — and the inside (the fin stack, the internal fans, the paste and pads) is professional territory for most people, for three compounding reasons: the case isn't designed for frequent opening, the warranty terms usually say so, and a laptop's thermal pads (the interface on the GPU and memory, not just the chip) are the part that gets done wrong expensively. The table below is the cross-machine summary — where the first checks diverge and where the professional line sits for each. And the laptop's version of the trend question, because it's the one that decides repair-vs-replace: a laptop several years old whose baseline has crept up, whose vents are clean from the outside, and whose fan is audible but weak is a laptop with an internal story — and on a machine where the internal work is a service visit, that story is a cost conversation, which is exactly what the final section is for.

A case is an airflow machine, and like any machine it has intakes, exhausts, and a path — and like the room-and-spot layer, it obeys the same law at a smaller scale: cool air in, a path across the heat, hot air out. The design goal isn't fan count — it's pressure and path. A case with more intake than exhaust sits at slight positive pressure (cool air pushed in, hot air forced out through the gaps — the configuration most cases are meant to run), and the path's job is to get that cool air across the two heat sources (the CPU's cooler and the GPU) before it leaves. The failure modes are the mirror images of the room's: no intake (a case with only exhaust fans, pulling from wherever — often its own warm interior), a blocked path (cable bundles across the intake, a dense drive cage, a filter packed with the dust this section keeps meeting), recirculation (the rear exhaust aimed at the side intake — the case's version of the cupboard), and the location failures from the airflow section (the wall, the cabinet). Each one has the same signature: fans working, numbers higher than the hardware should make, and improvement the moment the path opens.

The checks and the cheap fixes, in the order that respects “no parts required.” Orientation: every case fan has a direction — the frame's stiffer side is the back, the label side usually faces the outgoing air, and the manual states it; intake fans face into the case (front, bottom), exhaust face out (rear, top), and a fan installed backwards is a fan actively uncooling. The path: with the case door off (or the side panel open, briefly, hands clear), trace the air — does the front/bottom intake's air reach the GPU? Does the CPU cooler's exhaust have somewhere to go (a top exhaust is the classic partner to a tower cooler)? The two highest-value layout facts: the GPU wants the intake air, and the CPU cooler wants the air crossing its fins to leave through the top or rear. The filters: the front and bottom filters are where the room's dust lands first — the cleaning procedure covers them, and a filter check belongs in the rhythm as its own item. The count, last: where fans are missing, the standard cheap build is one or two front intakes and a rear (and often top) exhaust — but the honest note is that adding a fan to a case with no path improves the noise more than the numbers, and the path fixes above are free while the fan isn't.

Where this section ends, and what it rules in. A case whose airflow is fixed — intakes feeding, path clear, exhausts escaping, filters clean — and whose numbers are still where they were has said its piece: the constraint is a component, not a path, and the causes group (the cooler's mount and match, the paste, a fan's bearing) is the next read, with the baseline as the judge of whether each fix moved the needle. The overkill line, because it's the one people cross: a case full of expensive fans in a wrong configuration cools worse than a case with two cheap fans in the right one, and “optimize” in this section's vocabulary means direction, path, and pressure — not quantity. And the seasonal coda, shared with every other section: the case's design meets the room's temperature every day, and a case that's fine in winter and marginal in August is a case whose headroom is thinner than its winter numbers suggest — which is the argument for the baseline log covering both seasons, so the August version of the machine is measured, not guessed.

Gaming is the workload that tests the whole machine, because a modern game is a sustained dual load — the CPU and the GPU both working, together, for an hour — which is exactly the condition a cooling system was (or wasn't) designed for. The first thing to get right is the expectation, because the failure and the design share a symptom: a gaming machine under a real game is supposed to be warm and audible. Fans up, case warm, GPU in its 60s–80s (the context bands, not limits) — that's the machine doing its job. The failure signatures are specific and they're the ones worth acting on: temperatures that hit the throttle point within the first minutes of a session (the cooling can't keep up from the start), a mid-game slowdown or stutter that eases when you stop (the throttle arriving), a shutdown in a long session (the protection giving up), and the trend version — the same game, the same room, throttling sooner each month. A machine that runs warm and steady through the whole session, game after game, is a machine that's fine, however loud it is.

The diagnosis, using the tools already on this page. Read the temps in-game (the monitoring in the background, or the card's own overlay) — CPU, GPU, and the shape of the curve: a fast climb to a ceiling is the cooling-limited shape; a slow creep over the session is the ambient-plus-accumulation shape; and the CPU/GPU split localizes (the GPU section's trick) — a hot card with a cool CPU is the card's story, and vice versa. Test the levers that are instant and free: lower the resolution or the heaviest settings for one session — if the GPU's numbers and the fan noise drop with the settings, the card's load was the driver (which is normal physics, not a fault — but it tells you how much headroom the settings buy); and cap the frame rate — an uncapped game in a fast machine can push the GPU to 100% for frames nobody can see, and a cap is a real, immediate heat reduction that most people never try. Run the chain checks the gaming pattern implies: the dust (gaming machines are the ones that run hot often, and hot often is where dust earns its keep — the section), the case's intake air reaching the card (the airflow section), and the room (the August case — the ambient test).

The honest ordering, which is the section's point. A gaming machine that throttles in the games it was bought for has a cooling problem, and the settings are a bridge, not a fix — running the games at lower settings to keep the temperatures down is how a marginal machine gets another year, and it's worth knowing which of those two things you're doing. The durable order: the chain first (dust, airflow, the fans, the cooler's match — a card or CPU that outgrew its cooling is the upgrade conversation), the levers second (the cap, the settings, the power limit or undervolt as the fine trim), and the room whenever (the window fan is free and it works). And the logging habit earns its keep here more than anywhere else on the page, because gaming is repeatable: the same title, the same settings, the same room, logged across weeks, turns “it's been running hot lately” into a date and a number — and a number with a date is what the professional conversation (or the parts order) actually runs on.

Sustained workloads — a long render, an export, a compile, a batch — differ from gaming in the one way that changes the thermal story: they're flat. A game breathes (bursts and lulls); a render holds the machine near its limit for thirty, sixty, ninety minutes straight, which tests sustained heat removal in a way bursts never do. The consequence is that a machine can pass every gaming test and still fail the render — and the “it only gets hot when I render” case is often not a fault at all, but a machine doing more sustained work than it was designed for. That distinction matters, because the two versions have different answers: a machine whose cooling was always marginal for the work now being done needs the headroom conversation (the cooler's match, the power levers, or the honest “this job outgrew this box” call), while a machine that used to render fine and now throttles the same project is an accumulation or a failure story (the chain, the failure signs) — and the trend log is what separates the two, because “the same render, throttling earlier each month” is the second version with a timestamp.

The levers, in the order that respects the work. The chain, first and as always: dust, airflow, fans, paste — a sustained load exposes an undersized or degraded cooling system that lighter work hid, and the causes group applies unchanged; a render machine that's dusty is a render machine that's dusty, and the clean is the same fix at any workload. The power and clock levers, which matter more here than anywhere else on the page: a render is the workload where a power limit or an undervolt (the software section) buys the most — a few percent of speed for a meaningful temperature and noise reduction, over an hour of work, is a trade most rendering users take happily, and it's the lever that turns a “throttles at minute forty” render into a “finishes at minute forty-three” one. The workflow levers, which are free: schedule the heavy renders for when the room is coolest (the overnight render is a thermal tactic, not just a convenience one); checkpoint the work (a thermal shutdown mid-render is the specific cost this section exists to warn about — the shutdown protects the machine at the price of the render, and checkpoints are how you cap that price); and split where the software allows (a long render in segments with cooldowns between is slower in theory and often faster in practice on a marginal machine, because it never reaches the throttle wall). The honest ceiling: if the chain is clean, the levers are spent, and the machine still can't hold the workload, the answer is the hardware conversation — more cooling, a different machine for the job, or a different schedule for the machine — and it's a purchase decision wearing a thermal costume, which is fine to make, as long as it's made as a purchase decision.

One frame that keeps this section useful for everyone, not just the renderers: “heavy workload” is relative to the machine, and the question is never “is this work heavy?” but “is this work heavier than this machine's cooling can sustain?” — which is a measurable question (the delta and trend, the throttle behavior) rather than a vibes one. A modest machine doing a modest render that it can sustain is fine at any temperature its design produces; a flagship doing a flagship render that it throttles is not fine at any temperature. The workload sections of this page (this one and the gaming one) are the same law applied to the two sustained loads people actually hit, and both end at the same place: the cooling chain, the power levers, and — where the machine has genuinely been outworked — the honest conversation about what the machine is for.

Idle heat is the most telling symptom on this page, and the reason is the arithmetic: a machine at idle is producing a small amount of heat, and a healthy cooling chain moves a small amount of heat effortlessly — so a machine that's hot at idle, in a cool room, doing nothing, is a machine whose chain is broken or whose “idle” isn't idle. Only those two explanations exist, which is why this section is a two-branch procedure rather than a list of possibilities. The first branch — is it really idle? — is checked first because it's the cheapest test on the page: the background usage pass (Task Manager / Activity Monitor, sorted by CPU, watched for a minute or two with nothing open) looks for the hidden work — the update settling, the scan running, the sync client spinning, the miner pattern (high CPU with the machine demonstrably unused). If the CPU is busy, the heat has a source, and the fix is the source (let the update finish, restart the app, run the scan) — with the honest note that a high CPU is only a thermal problem if the temperatures follow it into trouble, which the readings settle. If the CPU is genuinely quiet and the machine is still hot, the source branch is closed and the second branch opens: the cooling chain isn't moving even the idle heat — which is a broken link, and broken links have names.

The second branch, link by link, because the idle-heat signature narrows the suspects more than any other symptom. The fan, first and specifically: many fan curves spin the fans down at idle — which means “hot at idle with no fan noise” has a precise reading: the control has switched the fan off (or it's dead), and whatever heat the idle machine is making has nothing to move it. Check the fan's actual state (the fan section: is it powered, is it turning, is the curve the culprit — the BIOS and software control sections own the lazy-curve branch). A fan that's off when it should be at its idle speed, or dead outright, on a machine that's warm at rest, is the finding — and it's the one where the fix (the fan, or the control) is usually the whole story. The dust, at its end stage: a machine clogged badly enough (the dust section's timeline, run to completion) stops moving even idle heat — the fins blanket over, the airflow chokes, and the last symptom to appear is the idle one, which is why “it's hot even when I'm not using it” often arrives as the final month of a long dust story. The clean is the test, and the expected result (a visible drop in the idle number within a day) is the confirmation. Placement, the laptop's version: a laptop “idling” on a duvet is not idling — it's running its ambient heat into a blocked intake, and the laptop section's surface rule is the fix, sometimes the entire fix.

What the two branches buy you, and the red flag that ends the section. Run both — the background pass and the chain check — and the idle-heat case resolves into one of four clean answers: hidden work found and dealt with (the machine's fine, the work wasn't); a fan or control fault found and fixed (the chain's restored); a dust story confirmed by the clean's result (the rhythm starts today); or — the red flag — a machine that's hot at idle in a cool room, with a quiet CPU, a working fan, and a clean interior. That combination has exhausted the cheap explanations, and it's the one where the remaining suspects are the paste and the cooler's interface (the paste section), the chip's own behavior, or the board's monitoring — and the honest move is the logged baseline in hand and the professional section open, because “hot at idle with everything checked” is the description a technician needs to start at the right end of the machine. Idle heat is the symptom that flatters honesty on this page: it's the one that can't be explained by a hot room, a heavy game, or a new workload, which is why it's the one that most often turns out to be a real fault — and the one most worth the two-branch procedure.

On most desktops, the fan policy lives in the BIOS/UEFI — the map from temperature to fan speed (the curve), plus a profile or two (quiet, balanced, performance) that are presets of that map. That makes the firmware the right place for two specific findings and the wrong place for most others. The right places: a machine whose fans are lazy — a curve set (or drifted) so low that the machine runs hot at speeds a balanced profile wouldn't allow — where moving to the balanced or performance profile is the direct fix; and the boot-time data — the POST screen's CPU temperature, read before the operating system loads anything, is a genuinely useful data point (the chip's temperature with no software work at all, in the room's air), and the “CPU fan error” message from the fan section is a BIOS finding, reported by the board at startup. The wrong places: a machine whose problem is dust, paste, or a dead fan — no curve fixes a clogged fin, and a curve cranked to maximum on a broken chain buys noise and bearing wear for less cooling than people expect. The honest framing: the BIOS tunes the mover's policy; it can't repair the mover or the path.

The safe work, and the one risky procedure that lives in this neighborhood. The safe work is reading and profile selection: enter the firmware (the standard key at startup, per the board), note the fan profile and the POST temperature, and where the finding is a lazy curve, choose the balanced or performance profile and test — the baseline before and after is what shows whether the profile change moved the numbers, and a manual curve (available on some boards) is the confident-user version of the same fix, done in small steps with the same logging. The risky procedure is the BIOS update, which deserves its own paragraph because “update the BIOS to fix the fans” is advice people actually follow: a firmware update can fix a genuine curve bug (and the vendor's release notes are where that claim would be stated), but a BIOS flash is also one of the few procedures where an interruption — a power loss, a forced shutdown — can leave the machine unbootable, which is why the standard cautions apply: a stable system, the vendor's exact process, the machine on reliable power, and no interruptions. The cost/benefit, stated plainly: on a machine with a documented curve problem, the update is a reasonable step; on a machine with “it's a bit hot,” it's a risky procedure chasing a marginal gain, and the dust and airflow checks are the higher-value first moves.

Two things this section exists to keep people from doing. First: do not disable or raise the thermal limits. Some firmwares expose the throttle points or the shutdown limits as “settings,” and they are not settings in the normal sense — they're the protection system, the same ladder from the shutdown section, and removing the railing doesn't make the cliff safer, it just makes the fall longer. A machine that needs its limits raised to do its work has a cooling problem, and the answer is the cooling. Second: do not run the fans at maximum permanently as a “fix.” A permanent 100% fan is a noise and a bearing-wear story with a temperature benefit that shrinks over time (the fans age faster at the ceiling, the bearing section's timeline on fast-forward), and it treats the symptom — the speed — while the cause (the chain) stays unfixed. The BIOS is where the fan's policy is set, and this section's whole job is keeping the policy in its lane: tune the curve where the curve is the finding, read the data the firmware offers for free, and leave the protection alone.

The operating-system and vendor layer controls how much heat the machine produces — which makes it the second family of levers (the first being the chain that removes heat), and the honest ordering stays the same: the chain first, the levers second, because no setting fixes a clogged fin. The levers, in the order of how often they're the actual finding. The power plan: the operating system's power scheme sets how aggressively the machine uses (and therefore how much heat it makes) — and a machine set to a maximum-performance plan when balanced was the default is a machine running hotter than its owner intends, often by a setting changed once and forgotten. The check is one minute (the plan's setting, in the OS's power options); the fix is choosing balanced, the default that exists for a reason; and the laptop note is that the vendor's control software (the fan and performance profiles) sits on top of the OS plan and usually matters more — check it there first, and treat the third-party “optimizer” and “fan booster” utilities with the skepticism the fan section recommends: they rarely touch the real controls, and the ones that do touch them do so without the vendor's knowledge of the machine. The drivers: a GPU driver update can change the card's power and fan behavior, which makes “it got hotter after the update” a real pattern with a real test — the rollback (the driver's previous version) is the check, and if the numbers improve on the old driver, the driver is in the story (and the vendor's support channel is where a regression like that belongs, with the logged numbers as the evidence).

The levers that genuinely move heat, for the people who want the fine trim. The frame cap (gaming): capping the frame rate below what the hardware can produce stops the GPU from working at 100% for frames nobody can see — an immediate, free, fully reversible heat reduction, and the one “gaming” fix that costs nothing (the gaming section uses it as a diagnostic as much as a fix). The power limit (CPU and/or GPU, in the vendor's tool where offered): telling the chip to draw less power — a few percent of performance for a real temperature reduction, the render machine's favorite trade (the workload section). The undervolt (the advanced version of the same idea): running the chip at a slightly lower voltage for the same speed produces less heat at the same work — per-chip, done in small steps, tested, and fully reversible, and one of the best heat-per-performance moves available to a user where it's supported; the honest limits are that it's an advanced adjustment (a too-aggressive undervolt shows up as instability, and the fix is walking it back), that many modern laptops lock it down entirely (don't force it — the locked version is the vendor's call), and that it reduces heat produced, which is the lever's whole domain: an undervolt on a dust-clogged machine is a smaller fire in a blocked chimney. And the anti-list, because it's half the section: the “cleaner/booster” utilities that promise thermal fixes don't touch the cooling chain at all, and an overclock — added at some point, sometimes by a “gaming mode” button, sometimes by hand — is heat added by design, which is why “it's been hotter since I turned on the boost” is an overclock story, and the fix is the overclock, not the cooling.

What the software layer can and cannot be, stated as the section's close. It can reduce the heat the machine makes (the plan, the cap, the limit, the undervolt), restore a control that was changed or regressed (the profile, the driver rollback), and surface a finding the hardware checks can't see (the lazy curve behind a hot-idle machine, the driver behind a post-update climb). It cannot move air, clear a fin, or replace an interface — the chain's work is the chain's, and a machine whose numbers don't improve after the settings are in order has said the constraint is physical, which routes it back to the causes group and, where the chain is verified clean, to the failure-signs conversation. The logging habit is the thread through all of it: every lever on this page is a change, and a change is only a finding if the baseline is there to compare against — set the limit, log the numbers, keep or walk it back. That's the whole method in one sentence, and it's the method the prevention section turns into a habit.

The clean is the highest-value physical procedure on this page — the fix behind most “worse over time” machines — and it's also the one with the specific safety rules that are easy to get wrong, so the rules come before the steps. Unplug and wait (the machine is off is not the machine is safe — the full power-down and a moment's wait, as every other case-work section on this page states). Discharge yourself before touching internals (bare metal on the case; the handling notes from the sister guides apply — grip components by edges, work away from carpet). The compressed-air rule, the one that matters most: hold the fan still while you blow. A fan's bearing is free to spin, and a burst of air can drive it to speeds it was never designed for — an overspun fan is a damaged fan, which is how a cleaning session creates the very bearing problem it was meant to prevent. Short bursts, the can upright, the fan's blades held with a finger (clear of the rotation path), and the dust has somewhere to go (a desktop: out of the case; a laptop: out of the vents, into the room, not deeper). The laptop's scope, stated up front: the external vents and the keyboard-edge intake are the owner's clean; the fin stack inside is the professional column for most people, and the warranty note applies.

The procedure, in order. 1. Power down properly — shut down, unplug (laptop: unplug the charger; remove the battery where the design allows), wait a minute. 2. The outside pass, both machine types — the vents: look first (the visible dust is the map), then the short-burst air at each vent with the fans held; the filters (desktop front/bottom — remove, clean, refit; a filter that's packed is the intake's story in one object); the case's exterior and the area around it (the dust that settles on a case's shell is the room's dust budget, spent). 3. The desktop interior, for the comfortable — the side panel off, the same rules inside: the case fans (held, short bursts), the CPU cooler's fins (the careful pass — packed dust wants the can plus a soft brush at the fins' base, not fingers, and not a burst so close it bends a fin), the GPU card's fin stack from the side (the GPU section's check, now the fix), and the drive bays and the case floor (where the fine dust lands and re-suspends). 4. The reassembly and the test — everything back, the machine powered on, the first boot watched (the fans turning, no new noises — a new noise after a clean is a fan that was looser than it looked, and it's noted now, not discovered in a month), and the baseline relogged after a day or two of normal use. The expected result, stated because it's the section's payoff: a machine that was running 10–15 degrees above its old baseline comes back toward it within days, the fans quiet down at the same work, and the throttle behavior — if that's what it was — simply stops happening.

The honest boundaries, which are the section's real value. A clean is a reset of the accumulation clock, not a permanent state — the dust comes back at the room's rate (the pets-and-carpet question again), which is why the clean's proper ending is the rhythm, not the heroics. A clean that doesn't improve the numbers has ruled dust out of the story — a useful negative result that routes to the fan, the paste, or the cooler sections with the accumulation explanation removed. And the stop rules, stated with the rest of the page's stops: a burning smell at any point during the clean (the machine was closer to the electrical end than the dust story suggested — stop, unplug, professional); a fan that comes apart in your hand (it was that tired — replace it, the section); and the laptop's internals, the AIO, and any machine you're not comfortable with — the clean is the one procedure where “skip it and pay a technician” is a fully reasonable answer, because the technician's clean includes the inside of the case the owner's clean doesn't reach, and on a several-years-dusty machine, that's often where the dust was thickest.

Prevention works on this problem for the reason the diagnosis section kept returning to: the real causes are slow. Dust accumulates over months, paste dries over years, bearings wear over time — none of them arrive as an event, which means none of them need to be caught as one. A machine on a rhythm rarely surprises its owner, because the baseline log shows the creep while it's still a number and not a shutdown. The rhythm, honestly scaled (it's maintenance, not a hobby): every few months — two minutes at the vents (a look, and the airflow feel under load), and the filter clean on a desktop (it's the part the room's dust hits first). Every six to twelve months — the proper clean (the procedure; shorter on the pets-and-carpet schedule, and after any move or dusty season), plus the baseline relog (the same workload, the same room, the numbers next to last time's — the comparison is the point, and five minutes of logging is the entire early-warning system this page offers). Whenever — the placement habits as defaults rather than decisions (the laptop's hard surface, the desktop's clearance, the room's temperature in summer), the update discipline (the drivers and firmware that fix the curve bugs the BIOS section mentioned), and the workload honesty (knowing what the machine is for, so a machine that's outgrown its job gets the conversation in the workload section instead of another year of throttling).

The habits worth naming individually, because each one fails silently. The surface default — a laptop lives on hard surfaces; the duvet is where laptops go to throttle, and the habit costs nothing and the failure mode (the hot bottom on the bed, the blanket's insulation doing its quiet work) is the most common laptop story there is. The room awareness — the machine's room is part of the machine; a window in August, a heater in January, a closed office in summer — the ambient test made into a habit is just “know your room's temperature in the season you're in,” and it explains the seasonal version of every thermal complaint. The baseline log — the five lines from the diagnosis section, kept as a habit rather than an emergency: date, workload, the numbers (or the time-to-slowdown), the room, what changed. It's the difference between “it's been acting up” and “the load number went from 78 to 91 over three months, same room” — and the second sentence is a diagnosis with a date, a cause's fingerprint (the creep is the accumulation's), and a repair's ticket all at once. The move discipline — after any move, the ten-minute check (the sister guide's list applies: the connections, the placement, the first-boot watch), because a moved machine is a machine whose chain has been shaken, and the shake shows up as heat before it shows up as anything else.

The frame that makes the section true: prevention is the diagnosis, run early and often. Every check on the rhythm — the vent look, the airflow feel, the baseline compare — is one of the tree's steps, done while the answer is still “a little dust” instead of “a shutdown.” That's the whole argument for the page's structure, in the prevention's voice: the cooling chain has four links, each degrades slowly, and the machine tells you about each one in the same languages (the numbers, the fans, the behavior) long before the protection ladder's last rung. A machine whose owner reads those languages on a rhythm is a machine that gets its clean in spring instead of its shutdown in August — and the checklist at the end of this page is the rhythm reduced to ten ticks, which is the form a habit actually takes.

The distinction this section exists to draw: “needs cleaning” and “is failing” produce the same headline symptom (a hot machine), and the difference is in the pattern's response to the fixes. A machine that's dirty improves when it's cleaned, a machine that's placed badly improves when it's moved, a machine whose curve is lazy improves when it's tuned — and a machine that's failing improves from none of those, or improves and then slides back, because the thing degrading is a component with a lifespan, not a condition with a remedy. The failure signatures, by component. The fan bearing (the most common thermal failure): the noise that changes character — the steady whoosh becoming a grind, a whir, a wobble; the speed that becomes erratic with no change in load; and the end state, the fan that slows and stops. Bearings don't get better, the fan section says, and this is where that sentence becomes a purchase: the replacement fan, the cheap and standard part, is the fix — while the machine still boots, which is the window. The AIO pump (the liquid cooler's defining failure): the hum that changes or stops, the CPU running hot while its fans spin fine, the tube that's warm at one end and cool at the other (flow, or the memory of it) — and the leak signs, which are the immediate-stop set: dampness, residue, any fluid where fluid shouldn't be. A pump is not user-serviceable; a leak is not a wait-and-see. Both end at the professional column, the pump as a unit replacement, the leak as a stop-now. The progression pattern, which belongs to no single component: the machine that shuts down at lower and lower loads over weeks — the same game that ran an hour now trips at twenty minutes — is a machine whose headroom is being consumed by something that isn't stopping, and it's the pattern that most often converts a “maintenance” conversation into a “repair or replace” one.

The aging context, because it changes the decisions. A machine five to seven years old is a machine whose slow links are all near the end of their clocks at once — the paste has done its years, the bearings have done theirs, the dust has had the longest runway — and a several-year-old machine that starts showing the thermal story is often several failures sharing one symptom, which is the honest version of “it's just getting old.” That's not a verdict on the machine; it's information for the economics. The economics, stated the way the page states its other honest frames: the fan and the paste are the cheap end (a part and an hour, DIY or a modest service); the AIO is the middle (a unit, priced like one); the board — and the board is where a machine that runs hot despite a verified-good cooling chain starts to look (the heat production or the monitoring, not the removal) — is the “is this machine worth it” end, where the repair's cost meets the machine's age, its role, and its replacement's price in the same room. And the thread that runs through all of it, the one the immediate-actions section planted: a thermally unstable machine is a data risk — the shutdowns don't care what's open, and the backup habit is the first step of the failure conversation, before the repair quote, because the machine that's failing its cooling is the one most likely to fail its power at the worst moment.

How to use this section as a decision rather than a worry. Run the chain's fixes in the page's order — the clean, the placement, the fan check, the paste question where it applies, the baseline after each — and watch the response. Improvement at any step names the cause and ends the story (the common ending); no improvement, or improvement that slides back, moves the suspicion down this section's list (the bearing, the pump, the progression) and toward the professional; and the stop signs — the smell, the leak, the erratic fan on a hot machine, the lower-and-lower loads — skip the list entirely and go to the next section directly, because they're the conditions where continued use has a cost that isn't theoretical. The reframe that closes it: a thermal failure, properly read, is a machine that has been reporting its state in the page's languages (the numbers' creep, the fan's changing voice, the shutdowns' shortening patience) for longer than it took to notice — and the rhythm is how next year's machine gets the report in spring, while the fix is still the cheap one.

The stop list, collected with the reasoning the way the power guide collects its stops. Immediately, no diagnosis: a burning smell or smoke (power off, unplug, no retries — the immediate table's last row, and the reason it's there); signs of a liquid-cooler leak (the dampness, the residue — the failure section's stop-now set); a swollen or damaged battery on a laptop (the lithium-safety stop, shared with the sister guides — don't press it, don't use it, professional handling); and liquid in the machine's history, which carries the same rule as the power guide's: no power until it's certain, and the data question raised early. The strong-consider stops: a laptop that's hot at idle with clean external vents and an audible fan (the internal story — the fins, the internal fans, the pads — is the professional's craft, and the warranty terms are the second reason to make it a call rather than a prying session); repeated thermal shutdowns that survive the full cheap pass (clean, placement, fans, settings — the tree's entire first half — the constraint is a component, and the failure section is the list); a machine that runs hot despite a verified-good chain (the board's story, the “heat production or monitoring” end of the failure economics); and any machine under warranty where opening it would change the terms (the self-service line is the warranty's line, and the call is often the covered path — with the log from below as the intake form, which the warranty desk will ask for anyway).

What to bring, because a prepared thermal appointment is a shorter and cheaper one. The temperature log — the baseline, with its dates, workloads, and room notes; the trend is the finding, and a logged trend is the difference between “it's hot” and “the load number went 78→91 over three months, shutdowns since June.” The pattern in words — when (the workloads, the idle cases, the seasons), how long it's been worsening, and what the machine does at the end (the throttle, the shutdown, the freeze — the ladder's rung); the five-line format from the diagnosis section is the format. The environment — the room, the spot, the dust context (the pets, the carpet, the last clean's date — the accumulation question), because a technician who knows the machine lived on a radiator for two winters reads the numbers differently. The history — the last service (the paste-and-mount question), any overclock or “gaming mode” (the settings that add heat), the machine's age and its role. And the data question, asked first and honestly — a machine that's thermally unstable is a machine that can lose power at the worst moment, and if the data matters, the backup happens before the repair, not after the quote; on a machine with a failing drive's acoustic company (the clicking from the sister guide's world), the recovery conversation starts before the thermal one ends.

The call, framed so the decision is proportionate. A thermal repair is often a clean-plus-paste — a real service, priced like one, with the diagnostic fee as the entry and the machine's age and value as the honest variables the failure section put on the table; the DIY work this page has prepared (the logged baseline, the pattern, the ruled-out links) is exactly the work that shrinks the diagnostic half, which is why the page's method pays off in the professional's chair as much as in the case. Two last frames, the page's own. The first: the protection is working — a machine that throttles and shuts down is a machine whose safety systems are doing their job, and “it shuts down when it gets hot” is the feature that has been buying the time this whole page describes; the goal of the repair is to get the machine out of the protection's range, and the goal of the stop list is to not spend that bought time on a machine that's past the point where use is safe. The second: the machine that leaves here is a machine that's been understood — its chain tested link by link, its baseline logged, its pattern named — and a hot machine that's been understood is fixable, replaceable, or (where the numbers say “warm but stable, the design's cost”) simply accepted, and all three of those are better endings than a hot machine that's been guessing.