Microsoft’s account of starting equipment at its Mount Pleasant data center begins with a problem that has little to do with the intelligence of an AI model. Neighbors heard a tonal hum. In an April 2026 update, the company traced it to cooling fans operating at high speed. Later updates described mitigation and continuing evaluation. Microsoft’s public chronology is a reminder that a service presented as software is also a physical installation operating beside other people.
The issue sits alongside a different Microsoft commitment: new data-center designs intended to avoid evaporating water for cooling. The two subjects are connected by the need to remove heat, but one does not answer the other. A facility can improve its water performance while still needing to manage sound, electricity use and the effects of starting or expanding equipment.
The water claim has a defined scope
In December 2024, Microsoft described closed-loop, chip-level cooling and said all new designs had begun using the approach that August. It identified Phoenix and Mount Pleasant as locations for pilots in 2026. This was a design and rollout statement, not evidence that every existing Microsoft data center had already changed its cooling system.
The phrase “zero water for cooling” also needs to stay attached to the boundary Microsoft described. It concerns the cooling process, particularly avoiding continuous evaporative use. It should not be expanded into a claim that constructing, operating or supplying the entire facility has no water footprint. Electricity generation and equipment manufacturing have their own effects, outside the narrow cooling measure.
Commissioning is an operating phase
At Mount Pleasant, Microsoft said in April that equipment startup had produced sound it did not expect to travel as far as it did. The company reported mitigation in June and said in July that it continued evaluating sound and additional reduction measures. These are the operator’s statements, not an independent measurement made for this article, and they should be read as a dated sequence rather than a permanent conclusion about present conditions.
The larger lesson is that startup deserves its own plan. Testing fans, pumps, generators and controls is necessary before a facility reaches stable operation. Those activities can create conditions different from the finished design’s expected performance. A project that explains only its eventual operating state may leave neighbors unprepared for the period when equipment is being commissioned and adjusted.
Denser computing changes the engineering problem
NVIDIA’s July 2026 account of Vera Rubin emphasizes liquid-cooled computing trays and higher-temperature cooling. Such changes are part of a wider effort to deliver more computing within a physical installation. They also redistribute work among the server, the cooling loop and the facility that ultimately releases the heat.
Moving heat efficiently from a chip is not the same as making heat disappear. The installation must still manage it under local weather and operating conditions. That is why a server-level efficiency claim cannot settle a community-level question by itself. The relevant evidence includes the complete system at the site, including periods of high demand and equipment maintenance.
Environmental measures should not be merged
Google’s 2026 Environmental Report overview illustrates the importance of reporting separate measures: it discusses electricity growth and emissions outcomes independently. The same discipline should apply to cooling. Water consumption, electricity demand, noise and emissions each need their own definition, measurement period and geographic boundary.
A single green label can obscure trade-offs that a more detailed account would make manageable. For example, the value of reduced local water demand depends partly on water conditions at the site, while the consequences of additional electricity depend on the supplying system. Neither question is answered by assuming that all data centers operate in the same environment.
Autonomy does not remove accountability
An AI company may buy computing as a service without owning the building. That arrangement can make the physical consequences less visible to the product team, but it does not remove them from the service’s operating model. Customers increasingly asking where data is processed have reason to ask how that location is powered, cooled and supported as well.
For an operator, credibility comes from publishing a clear account of performance and responding when measured experience differs from expectations. That includes explaining what changed, what was tested and what remains under review. A dated update is more useful than a broad reassurance because it lets readers distinguish an initial diagnosis from a verified remedy.
The sequence of Microsoft’s updates matters. An early statement identifying a source of noise is evidence of diagnosis. A later statement describing mitigation is evidence of an attempted remedy. A continuing commitment to monitoring leaves open the need for further measurement. Collapsing those stages into either “the problem is solved” or “nothing has changed” would discard useful information. For a new facility, a published operating history can become a more credible account of its relationship with neighbors than a design specification written before the equipment was turned on.
Microsoft’s public cooling and noise accounts should therefore be read together without collapsing them into one verdict. The water design addresses a genuine engineering constraint; the Mount Pleasant updates show another constraint emerging during startup. Autonomous AI will depend on facilities that can sustain both technical performance and an acceptable relationship with their surroundings. The physical neighbors remain part of that story even when the product is sold through an API.
Sources & evidence
This archive preserves its original editorial date. Sources describe the events and announcements discussed; they do not establish today’s status.


