How dust loads intake filters on an air-cooled site, why pressure drop beats a calendar, and what a skipped change costs in temperature and hardware life.
Nobody signs a hosting contract because of the filters. They sign it on price, power and delivery date, and the filters get mentioned once in a walkthrough and then forgotten until a row runs hot for no obvious reason. By then the cause is usually sitting in plain sight, loaded up with the dust it was put there to stop.
Why the intake needs a filter at all
An air-cooled row pulls a large volume of outside air across the machines and pushes it back out the other side. Whatever is in that air (dust, pollen, insulation fibre, chaff from a nearby field, road grit) ends up on the intake side of the row unless something stops it first. A filter is the thing that stops it, and it does that job by design: it is meant to load up. A clean filter after a year of service is a filter that was not doing anything. The question is never whether it collects material, it is whether the load on it is tracked and acted on before it starts working against the row instead of for it.
What sets the change rhythm
There is no single interval that fits every site, because the load on a filter is a function of the environment around it, not a fixed number of weeks. A site next to farmland sees a different dust profile in harvest season than it does in winter. A site near a road or a construction site sees more particulate than one in open country. A container at ground level draws in more than one mounted above the dust layer that settles near grade. Ask what is in the air at a given site, and ask whether the operator has changed the rhythm in response to it, or is running the same schedule regardless of season and location. A site that can describe how its environment has shaped its maintenance rhythm is telling you it is paying attention. A site that quotes one number for every location it runs is telling you the opposite, even if the number sounds reasonable on its own.
Pressure drop is the number that matters, a calendar is not
The reliable way to know a filter needs changing is to measure the resistance it is putting up against the air trying to pass through it, commonly called the pressure drop across the filter. That number rises steadily as the filter loads, and it rises well before the change is visible to the eye or obvious from a walk down the row. A calendar-based schedule is a reasonable starting policy, but it is a guess dressed up as a plan, because it assumes every month puts the same load on the filter regardless of what blew past the intake that week. Ask whether pressure drop is measured at each site, how often, and what value triggers a change. If the answer is a date on a spreadsheet rather than a reading off the row, you are looking at a policy that will eventually be wrong in one direction or the other, either changing filters that still had life left or leaving a loaded one in place past the point it should have come out.
What a loaded filter costs
A filter that has loaded up does not fail cleanly. It restricts airflow gradually, and the effects show up in a chain that is easy to trace once you know to look for it. Less air moves across the row for the same fan speed, so the temperature spread across the machines widens even though nothing else has changed. The control system, if it is doing its job, responds by raising fan speed to compensate, which holds temperatures for a while at the cost of more power drawn by the fans themselves and more noise off the row. Eventually the fans run out of headroom, and the machines behind the worst-affected section of the filter start running hotter than the rest, which is where hashrate and hardware life both start to erode quietly, well before anything alarms or shuts down. No dust storm is needed for any of this. A filter left in place two intervals too long is enough, and the loss shows up on a fleet operator's side of the ledger as lower average hashrate and shorter component life, not as a line item the host ever has to explain.
Whose job the change is, and how it gets proven
A short conversation at the site walkthrough, or a clause in the agreement, settles most of this before it becomes a problem. This is the part to put in writing rather than assume. Ask, in the agreement rather than in conversation, who is responsible for filter changes: the operator as part of the hosting service, or the fleet owner as a separate arrangement. Then ask how the change is documented. A record that states a filter was changed on a given date, ideally against a pressure-drop reading before and after, is the record to ask for, because it turns a task that is easy to defer into one that leaves a trail. If the answer is that changes happen but nobody logs them, treat that the same way you would treat any other undocumented maintenance claim: as something you cannot verify after the fact, which is exactly when you would want to.
Before you sign, or at your next walkthrough, run through the following:
- Ask what drives the change interval at this specific site: a calendar, a measured pressure drop, or both.
- Ask to see a pressure-drop reading, not just a filter that looks clean.
- Ask who is contractually responsible for the change, and where that is written down.
- Ask how the change is logged, and whether you can see the log for your own row.
A filter change is one of the cheapest recurring tasks on a site, and it is also one of the easiest to defer without anyone noticing until the temperature spread on a row starts telling the story instead. The mechanism behind this sits alongside the broader airflow design covered in our guide to air-cooled container sites, and our operations page sets out the monitoring that runs alongside it: power draw and temperature in real time, with alerting on threshold breaches. How filters are handled at a given facility is something to check on the row itself, during a site visit before the service order.
