Power Billing in the Datacenter: kW Commit vs Metered

Power is the constraint that actually limits a datacenter, and it is the line item most likely to be priced badly. Sell it too cheaply and you subsidise your densest customers with your sparsest ones. Sell it as a flat rate per rack and you either lose money on the customer filling 8 kW or you overcharge the one drawing 1.5.

Here are the three models, what each one requires of your metering and your billing system, and where each goes wrong.

Model 1: included with space

A rack comes with a stated power allowance and no separate power line. Simple to sell and simple to invoice, and it works only while your customers are broadly similar.

It breaks the moment density varies. A customer at 1 kW and a customer at 6 kW pay the same for the same rack, and the second one is consuming the capacity you would otherwise sell to three more customers. Since power, not floor space, is what you run out of, this model quietly gives away your scarcest resource.

Reasonable use: small deployments, a well-defined product with an enforced cap, and a business that is not yet power-constrained.

Model 2: committed capacity

The customer commits to a capacity in kW and pays for it whether they draw it or not. You reserve it on the circuit and cannot sell it twice.

This is the model that matches the economics, because your cost is driven by provisioned capacity — the circuits, the UPS, the cooling and the generator all have to exist for the peak, not the average. Charging for the commitment charges for what you actually built.

It requires one thing to work: you must track provisioned capacity against available capacity per circuit and per rack, and refuse to oversell it. If commitments live in contracts and capacity lives in an electrical spreadsheet, you will eventually sell capacity you do not have, and you will find out when a breaker trips.

Model 3: metered consumption

You measure actual draw and bill it, usually with a capacity commitment underneath and metered overage above.

Fairest to the customer, most demanding on you. The decisions you have to make explicitly:

• What do you measure — energy or peak? kWh consumed and peak kW drawn are different quantities and produce different bills. Energy tracks usage; peak tracks the capacity you had to reserve. Many providers bill a capacity commitment plus metered energy, which reflects both cost drivers.
• Which peak? Instantaneous peaks are noisy. An averaging window, or a percentile, gives a number that reflects sustained load rather than a spike. Whatever you choose, write it in the contract in a way the customer can verify.
• A-side and B-side. Dual-fed racks draw across two feeds. Summing both is correct for energy and wrong for capacity, because the customer is not entitled to draw the full commit on each side simultaneously — that is what redundancy means. Be explicit, because getting this wrong doubles a bill.
• Where do you read? Branch circuit monitoring at the PDU is the normal answer. Per-outlet metering is finer and more expensive. Whatever you use, the customer will eventually want to see the same number you are billing from.

What this demands of billing

Metered power billing is a data pipeline, not a pricing setting. Something has to poll the PDUs, store a time series, aggregate it per customer per period, apply the commitment and overage rules, and produce an invoice line — on a schedule, without a person.

Three requirements that get skipped and then hurt:

The mapping from circuit to customer must be authoritative. A PDU outlet belongs to a rack position which belongs to a customer's service. If that chain lives partly in a DCIM tool and partly in billing, an equipment move silently misattributes power until somebody complains.

Gaps must be handled explicitly. Polling fails. Decide in advance whether a gap is treated as zero, interpolated, or flagged for review — and never let a monitoring outage silently reduce a bill.

The customer must be able to see the data. A power bill nobody can verify is a dispute waiting to happen. Exposing consumption in the portal converts most of those disputes into a self-answered question.

Pricing sanity checks

Whatever model you pick, know your all-in cost per kW per month — the energy itself plus the amortised UPS, cooling, generator, distribution and the PUE overhead that means every watt to the customer costs you more than a watt at the meter. That number is your floor.

Then decide your position deliberately. Bundling power into space is a simplicity play and costs you margin on dense customers. Metering everything is a fairness play and costs you infrastructure and support. Commit-plus-overage is where most providers end up because it matches how the costs actually behave.

How FluxBilling fits

FluxBilling tracks power allocation as part of rack management, so committed capacity is recorded against the rack and the circuit rather than living only in a contract — which is what makes overselling visible before it is a problem. Hardware inventory, rack position and the customer's service are the same records, so the mapping from a physical position to a billable customer does not depend on two systems agreeing. PDU and switch tracking is part of the network device layer, and metered overage billing runs as a scheduled step in the daily billing pass, the same mechanism used for IP transit overage.

An honest limit: how well automated metering works depends on what your PDUs expose and how they are integrated. Confirm the specifics for your hardware before assuming a fully hands-off pipeline — for some estates this is a plugin-builder project rather than a configuration.

See DCIM and power and PDU monitoring.

Closing thoughts

Work out your revenue per kW per rack across your customer base and sort it. The spread will be wider than you expect, and the customers at the bottom of that list are the ones consuming the capacity you would rather sell to the ones at the top. That single sorted list is usually a better argument for changing your power model than any pricing theory.