Data Centre Occupancy & Utilisation Models
Executive Summary
Key Takeaways
- ✓ Billed (contracted) capacity, actually utilised capacity, and total available capacity are three distinct states that should be modelled separately, since revenue tracks billed capacity while cost and remaining headroom track actual utilisation and available capacity.
- ✓ Under a take-or-pay contract structure, billed capacity can exceed actual utilisation for an extended period, and revenue is protected regardless, a distinction retail colocation occupancy modelling does not usually need to make as sharply.
- ✓ Remaining sellable capacity headroom should be calculated against the facility's binding constraint (power, space, or cooling), not simply against total nameplate capacity, to avoid overstating available growth room.
- ✓ Utilisation trends by density tier and by tenant vintage help distinguish genuine occupancy growth from mix-driven revenue changes that a single blended occupancy percentage would conceal.
Objective¶
This guide sets out how to model data centre occupancy and utilisation within Data Centre Financial Modelling, distinguishing billed, utilised, and available capacity.
Three Distinct Capacity States¶
Billed (contracted) capacity. The power or space a tenant is contractually obligated to pay for, whether or not fully used. This is what drives revenue directly.
Actual utilisation. The tenant's real power draw or space usage, which can lag billed capacity, particularly during a phased migration or ramp-up period, or under a take-or-pay contract structure.
Available (sellable) capacity. The facility's total remaining capacity that can still be contracted to new or existing tenants, bounded by the facility's binding constraint (power, space, or cooling). See Data Centre Capacity Planning Models.
A model that conflates these three states risks two distinct errors: overstating revenue durability if actual utilisation, rather than billed capacity, is treated as the revenue driver; and overstating remaining growth headroom if available capacity is calculated against nameplate capacity rather than the facility's actual binding constraint.
Billed Capacity as the Revenue Driver¶
Revenue should be modelled from billed (contracted) capacity, not actual utilisation, since under a take-or-pay contract structure the tenant is obligated to pay regardless of usage. This distinction matters most in hyperscale and larger colocation agreements where phased migration is common; retail colocation occupancy, typically billed closer to actual usage from the outset, requires the distinction less sharply, but the model should still track it explicitly rather than assume the two are always equal.
Calculating Remaining Headroom Against the Binding Constraint¶
Remaining sellable capacity should be calculated against whichever constraint, power, floor space, or cooling, is actually binding in the facility, not against total nameplate or design capacity. Calculating against nameplate capacity alone can materially overstate genuinely available growth room where a different constraint, commonly power or cooling as tenant density rises, in fact binds first.
Utilisation Trends by Density Tier¶
Occupancy and utilisation should be tracked by density tier and, where relevant, by tenant vintage, rather than reported as a single blended occupancy percentage. A single blended figure conceals whether growth is coming from new standard-density leasing or a shift toward higher-density tenants, each of which carries a different implication for remaining power and cooling headroom even at an identical reported occupancy percentage. See Rack Revenue Models for the corresponding pricing-side density tier discipline.
Common Construction Pitfalls¶
Actual utilisation used as the revenue driver instead of billed capacity. Understates revenue durability under a take-or-pay contract structure.
Remaining headroom calculated against nameplate capacity. Overstates genuinely available growth room where power or cooling binds first.
Single blended occupancy percentage. Conceals density mix shift and the differing headroom implications of standard-density versus high-density growth.
Recommended Practices¶
- Model revenue from billed (contracted) capacity, tracking the gap to actual utilisation separately.
- Calculate remaining sellable headroom against the facility's actual binding constraint, not nameplate capacity.
- Track occupancy and utilisation by density tier, not as a single blended percentage.
- Reassess the binding constraint periodically as tenant density mix evolves.
Continue Reading¶
Related Pillars¶
Related Technical Guides¶
Related Glossary¶
How OXXON tests thisRun a free structural check with FMAE
Frequently Asked Questions
What is the difference between billed capacity and actual utilisation?
Billed (contracted) capacity is what a tenant is paying for, whether or not it is fully using that capacity. Actual utilisation is the tenant's real power draw or space usage. The gap between the two matters because revenue tracks billed capacity, while facility cost and remaining sellable headroom track actual and available capacity.
Why can billed capacity exceed actual utilisation for an extended period?
Under a take-or-pay contract structure, common in hyperscale and larger colocation agreements, a tenant is obligated to pay for contracted capacity regardless of whether it is fully utilised yet, for example during a phased migration or growth ramp, so revenue can be fully protected even while actual utilisation lags.
How should remaining sellable capacity headroom be calculated?
Against the facility's actual binding constraint, power, floor space, or cooling, whichever is most limiting, not against total nameplate or design capacity, since calculating against nameplate capacity alone can overstate genuinely available growth room if a different constraint binds first.
Why track utilisation by density tier rather than as a single blended occupancy percentage?
Because a single blended occupancy percentage conceals whether occupancy growth is coming from new standard-density leasing or a shift toward higher-density tenants, each of which has a different implication for remaining power and cooling headroom even at the same reported occupancy percentage.
How does occupancy modelling differ between colocation and enterprise/captive facilities?
Colocation occupancy modelling tracks external tenant billed capacity against available capacity to forecast revenue. Enterprise/captive occupancy modelling tracks internal business unit consumption against available capacity purely as a cost-efficiency and capacity-planning metric, since there is no external tenant revenue.
Related Articles
Data Centre Financial Modelling
Data centre financial modelling is the discipline of modelling a data centre operator's revenue, cost, and capital structure from its capacity-denominated drivers, power, space, and cooling capacity, rack density, and tenant contract structure, rather than the generic market-price and headcount-growth drivers used in most corporate models, or the pure occupancy-and-lease-term drivers of conventional commercial real estate. This page is the hub for the Knowledge Centre's data centre financial modelling content: how colocation, hyperscale, and enterprise business models each require a distinct model architecture, how rack revenue and occupancy are decomposed into their separable underlying drivers, and how capacity planning and financial KPIs tie the model together, as this domain expands to cover operations, revenue, investment, and governance practice across the sector.
Colocation Financial Models
Colocation financial models project revenue from a diversified base of tenants leasing space and power in defined units, per rack or per kW of committed capacity, rather than a single anchor contract. This guide sets out how colocation revenue is decomposed into space/power revenue, cross-connect and ancillary fees, and how occupancy, pricing, and churn assumptions should be modelled as separable drivers rather than a single blended revenue-per-tenant figure.
Rack Revenue Models
Rack revenue is the core billing unit of colocation data centre revenue, priced per rack, per kW of committed power, or a hybrid of the two, with premium pricing for higher-density racks. This guide sets out the mechanics of rack-based pricing, density tiering, and how to model power draw billing and contract escalation without conflating them into a single blended average rate per rack.
Data Centre Capacity Planning Models
Data centre capacity is jointly constrained by power, floor space, and cooling capability, and the binding constraint can shift as tenant rack density changes. This guide sets out how to model capacity planning across all three constraints simultaneously, how phased capacity delivery should be scheduled against demand, and why treating any single constraint as the sole capacity driver risks overstating achievable revenue.
Take-or-Pay Contract
A take-or-pay contract is a common structure in hyperscale and larger colocation agreements under which the tenant is obligated to pay for its contracted capacity, whether measured in power, space, or both, regardless of whether it fully utilises that capacity during the contract term. This structure gives the operator a revenue floor independent of the tenant's actual utilisation pattern, which is particularly important during phased migrations or ramp-up periods when contracted capacity can materially exceed currently utilised capacity.