Why Colocation Contracts Need to Address Thermal Capacity

Colocation contracts commonly address space, power, cooling, connectivity, availability and commercial commitments. The rapid increase in high-density computing is making thermal capability a more important part of capacity discussions. Rack power and heat generation remain closely connected because the electrical energy consumed by IT equipment ultimately becomes heat that the facility must remove. Industry research shows that higher rack densities remain a major driver for direct liquid cooling adoption, while providers increasingly need to accommodate tenants with different cooling requirements. A customer can reserve a defined amount of electrical capacity without necessarily having the contractual ability to deploy every type of high-density hardware within that allocation. The gap can become important when a facility contains a mixture of conventional air-cooled racks and liquid-cooled systems. A contract that defines only kilowatts may leave uncertainty over the cooling infrastructure available to the customer at the point of deployment. A thermal capacity schedule could address that gap by translating the technical cooling capability of contracted space into measurable limits, responsibilities and expansion conditions.

Power Capacity Does Not Equal Cooling Capacity

A colocation customer usually understands its contracted power allocation in terms of kilowatts or megawatts. Thermal capability requires a more detailed description because the same electrical allocation can create different cooling requirements depending on rack density, equipment configuration and cooling architecture. An air-cooled rack and a direct-to-chip liquid-cooled rack can have different infrastructure requirements even when their electrical consumption falls within a similar broad power range. Cooling capacity may involve room-level systems, in-row equipment, rear-door heat exchangers, coolant distribution units and facility heat-rejection infrastructure. The actual boundary between those systems matters because responsibilities can cross between the provider and the tenant. A customer may own or operate part of the liquid loop while the provider supplies upstream cooling infrastructure. The contract can establish which capacity the customer is purchasing and which capacity remains subject to engineering approval. This distinction becomes important when a tenant expects to replace existing servers with higher-density equipment during a multi-year agreement. A thermal schedule could give both parties a reference point for determining whether that change remains within the original technical commitment.

Rack Density Should Become a Contractual Variable

Rack density provides a more useful starting point for thermal planning than a general statement that a facility is “AI-ready”. High-density deployments can place different demands on cooling distribution, heat rejection and white-space infrastructure. Uptime Institute’s 2025 cooling survey found that higher rack densities remained the leading reported driver for direct liquid cooling adoption, with 69% of respondents selecting the factor. The precise cooling requirement still depends on the equipment, rack configuration and facility design. A contract therefore should not assume that one rack-density number applies equally across every deployment. It could define permitted density bands, such as conventional, high-density and liquid-cooled zones, with specific technical requirements for each category. The schedule could state the maximum supported rack load, the applicable cooling method and the infrastructure available at each deployment location. Such definitions would reduce ambiguity when a tenant introduces equipment that was not contemplated during the original commercial negotiation. The provider would retain engineering controls without turning every hardware refresh into a completely new commercial negotiation. The customer would gain a clearer understanding of what its contracted capacity actually permits.

A Thermal Schedule Should Define More Than Kilowatts

A useful schedule could start with the contracted IT load but extend into the physical and operational characteristics of the cooling system. It could identify the maximum rack power supported within each designated area and distinguish between air-cooled, hybrid and liquid-cooled deployments. The document could record whether liquid cooling is available at the rack, row, room or facility level. It could identify the capacity of relevant coolant distribution equipment where such systems form part of the provider’s infrastructure. The schedule could specify supply and return temperature ranges where those parameters form part of the agreed operating envelope. It could define the fluid interface, connection requirements and responsibility for tenant-side distribution equipment where applicable. It could record redundancy arrangements and explain whether stated cooling capacity represents installed capacity, usable capacity or capacity available under a particular failure condition. The objective would be to create a technical baseline that procurement, engineering and operations teams can interpret consistently throughout the contract term.

The Contract Needs a Clear Cooling Boundary

Liquid cooling makes the boundary between facility infrastructure and IT equipment more complex. A direct-to-chip installation can require additional piping, coolant distribution equipment and connections within the white space. The tenant may provide some of that equipment, while the colocation provider may operate upstream systems. Responsibility for pumps, controls, fluid quality and maintenance can differ between facilities. A contract needs to describe those boundaries precisely because an outage affecting one part of the cooling chain can affect equipment owned by another party. The agreement should identify which components fall within the provider’s service obligations and which remain under tenant control. It should state the technical interface between those responsibilities rather than relying on general language covering mechanical infrastructure. This becomes more important when several liquid-cooling architectures operate within the same facility. Clear boundaries can reduce disputes over whether a thermal incident represents a facility service failure, tenant equipment failure or an interaction between the two systems.

Service Levels Need a Thermal Dimension

Service-level agreements in datacom facilities can address space, power, cooling and networking because these services are interdependent. ASHRAE notes that power and cooling redundancy can differ significantly between colocation centres and should be evaluated before a contract is signed. Liquid-cooled deployments introduce additional operating conditions that may require more specific technical definitions. A tenant could require confirmation that cooling water remains within agreed temperature limits or that a liquid distribution system maintains a specified flow condition. Those requirements need careful engineering because liquid-cooling systems can use different operating parameters. The contract could distinguish between provider-controlled conditions and tenant-controlled conditions to avoid assigning responsibility beyond either party’s technical boundary. It could define notification requirements when the provider changes cooling infrastructure, maintenance procedures or operating parameters. It could establish a process for validating a new rack configuration before deployment. Service credits, remedies or escalation mechanisms could then refer to measurable contractual conditions rather than broad statements about being “liquid-ready”.

Future Hardware Changes Make the Schedule More Important

A multi-year colocation agreement can span several generations of server hardware. The equipment installed at the beginning of the contract may have different rack density, cooling requirements and physical interfaces from hardware deployed later. Uptime Institute has identified the challenge of supporting different liquid-cooled IT configurations as hardware technology changes. A customer therefore needs more than a promise that the facility supports the hardware it intends to deploy on day one. The agreement should explain how future equipment will be assessed against the original thermal allocation. It could provide a change-control process for equipment that remains within agreed power and cooling limits. It could establish engineering review thresholds for configurations that exceed those limits. It could require the provider to identify available upgrade paths when the existing infrastructure cannot support the requested density.

A Thermal Schedule Can Protect Deployment Flexibility

A customer may reserve several megawatts for an AI deployment but distribute that load across racks with substantially different densities. The facility may support the aggregate power figure while lacking sufficient cooling distribution in the exact area where the customer wants to install the highest-density racks. That situation can create a practical restriction even when the contracted electrical allocation remains available. A thermal schedule could address the problem by tying capacity to defined zones, rack densities and cooling architectures. It could state how much high-density capacity exists today and how much remains available for future deployment. It could distinguish committed capacity from planned expansion capacity so that future upgrades do not appear to be guaranteed when they remain subject to engineering work. It could give the customer a measurable basis for comparing different facilities during procurement. The schedule would therefore become part of capacity due diligence rather than an appendix considered only after commercial terms have been agreed.

Thermal Capacity Should Be Tied to Location

Cooling capability cannot always be treated as a single number covering an entire data hall. Different rooms, rows and zones may have different electrical and mechanical configurations. A facility may reserve some areas for conventional workloads while another area supports higher-density deployments using liquid cooling. The contractual schedule should therefore identify where the specified capacity exists rather than assigning every thermal resource to the entire customer footprint. Location can matter for pipe routing, CDU placement, heat rejection, electrical distribution and physical access. A customer moving equipment between zones could trigger new engineering requirements even if its total IT load remains unchanged. The contract could define approved deployment areas and establish the technical process for relocating equipment. It could also specify whether a move consumes additional capacity or remains within the existing allocation.

Commissioning Evidence Should Support the Schedule

A thermal commitment should have technical evidence behind it rather than relying only on design intent. Commissioning can demonstrate whether installed systems operate according to their specified conditions under defined test scenarios. Uptime Institute has documented high-density liquid-cooling deployments where testing and commissioning helped validate the use of the technology before customer deployment. A provider could use commissioning records, equipment specifications and operational test results to establish the baseline for contracted cooling capacity. Performance measurements should identify the conditions under which the stated capacity applies. Those conditions might include ambient conditions, equipment operating state, redundancy configuration or other system-specific variables. The provider and tenant could agree on the evidence required when a new high-density deployment is introduced. A documented baseline would make future capacity discussions more objective because both parties would have an established technical reference.

Contracts May Need Thermal Change-Control Clauses

Hardware substitution can create a thermal change even when the customer considers the replacement commercially equivalent. A newer server may fit the same rack space while producing a different heat load or requiring a different cooling interface. Uptime Institute’s research shows that liquid cooling can impose hardware compatibility requirements that do not apply in the same way to conventional air cooling. The contract should therefore define the information the tenant must provide before installing materially different equipment. That information could include expected rack power, heat rejection method, cooling interface and operating temperature requirements. The provider could use those inputs to determine whether the proposed deployment remains within the agreed technical envelope. A review process should have defined response times so that engineering approval does not become an open-ended deployment delay. The agreement could distinguish routine hardware refreshes from material thermal changes that require additional infrastructure. This approach would preserve operational control without forcing the tenant to seek permission for every minor equipment change.

The Schedule Should Address Capacity Expansion

AI deployments can evolve significantly over the life of a colocation agreement. An expansion clause could define additional rack-density bands, additional liquid-cooling infrastructure or additional heat-rejection capacity. It could identify whether expansion depends on available space, power, mechanical infrastructure or equipment procurement. The customer could then distinguish between a contractual right to request additional capacity and an actual commitment from the provider to deliver it. Infrastructure expansion may require physical upgrades that cannot happen immediately. A clear process could establish feasibility reviews, commercial pricing and technical lead times before the tenant commits to a deployment schedule. The same mechanism could apply when a customer wants to convert an existing air-cooled area to support liquid-cooled equipment. Such provisions would make the contract more useful as a long-term infrastructure planning instrument rather than a static description of the original installation.

The Commercial Model May Need to Reflect Thermal Scarcity

Cooling infrastructure can become a constrained resource when demand for high-density deployments grows faster than available infrastructure. Current market evidence shows strong demand for high-density AI infrastructure and increasing adoption of liquid cooling. CBRE reported that AI-optimised facilities with liquid cooling and high-power-density racks captured rent premiums over conventional colocation space in North America during the second half of 2025. Colocation pricing also varies according to power requirements, market conditions and facility characteristics. A contract could therefore distinguish ordinary rack capacity from premium capacity that requires dedicated liquid-cooling infrastructure. The commercial structure could account for additional equipment, installation work and operational responsibilities associated with that deployment. The customer should understand whether the quoted price covers cooling infrastructure itself or only the electrical capacity that supports it. Providers may need to establish separate charges for tenant-specific CDUs, modifications or additional heat-rejection equipment where those costs arise. Commercial terms should remain linked to measurable technical requirements rather than broad descriptions such as “AI-ready”. A clearer connection between the engineering schedule and commercial schedule would give both parties better visibility into what the contracted capacity actually includes.

Thermal Capacity Could Become a Core Part of Colocation Due Diligence

Colocation procurement for high-density deployments increasingly needs to evaluate more than available megawatts and floor space. High-density computing makes the relationship between power, rack configuration and heat removal increasingly important. A provider can have substantial electrical capacity while offering only a smaller amount of capacity that supports a specific high-density cooling architecture. A customer assessing a facility should therefore ask how thermal capacity is measured, where it exists and what conditions apply to its use. The same questions should appear in contract negotiations when the deployment depends on liquid cooling or unusually high rack density. A thermal capacity schedule could document rack limits, cooling methods, interface responsibilities, operating conditions, redundancy and expansion mechanisms in one technical reference. The schedule should remain flexible enough to accommodate genuine technology changes without allowing either party to alter the underlying commercial commitment unilaterally. The strongest approach is not to create another generic specification sheet, but to establish a measurable technical baseline that connects the customer’s deployment rights with the infrastructure actually available.

The Contract Is Becoming Part of the Infrastructure Design

A colocation agreement increasingly has to describe the infrastructure conditions that determine whether contracted capacity can support the customer’s intended workload. Thermal performance belongs within that discussion because every watt consumed by IT equipment ultimately creates a heat-removal requirement. Liquid cooling adds further interfaces between tenant equipment and facility infrastructure, making responsibility and service boundaries more important than they were in conventional deployments. Meanwhile, rack densities and cooling architectures continue to change as new computing systems enter the market. A multi-year agreement should not attempt to predict every future server configuration, but it can define how those changes will be evaluated. The most useful contract will establish measurable limits, clear technical interfaces and a controlled process for expanding or modifying those limits. In addition, the same schedule can give procurement, engineering, operations and commercial teams a shared reference for evaluating deployment decisions. The result is a contract that does more than reserve space and power because it describes the thermal conditions under which that capacity can become usable computing infrastructure.