What participation pays, what it costs in lost production, and who keeps the difference when a hosted fleet is the load that stops.
Someone mentions that demand response pays, and the idea sounds simple: agree to stop drawing power when asked, collect a payment, repeat. The part that gets left out of that pitch is what stopping costs a hosted fleet, and who ends up holding that cost once the programme is running rather than being described in a sales call. The arithmetic is not complicated, but it only works if you have both sides of it in front of you.
What a demand response programme pays for
Demand response is not one product. Utilities and grid operators run several kinds of programmes, and they differ in who can call an event, how often they do, and what triggers a call. Some are tied to system-wide scarcity and get called only under real stress on the network. Others are tied to a specific local constraint, such as congestion on a particular line, and get called whenever that constraint is hit regardless of the wider market. A few are commercial arrangements between a utility and a large load, closer to a negotiated interruptible tariff than a public programme.
Before asking what a programme pays, ask what triggers it and who has the authority to call an event. A programme that is called on system-wide scarcity behaves very differently from one tied to a local constraint that recurs on a predictable schedule, even if the headline payment looks similar on paper.
Two payments, and only one costs you production
Most programmes structure payment in two parts. There is a standing payment for being enrolled and available to respond, sometimes called a capacity or availability payment, which is paid whether or not you are ever called during the period it covers. Then there is an event payment, paid only when you are called and only for the load you reduce during that call.
The distinction matters because the two payments behave completely differently against the fleet's economics. The availability payment does not require lost production, though most programmes penalise a load that fails to respond when called. The event payment is the opposite: it is compensation for production you did not get to run, and whether to take it depends entirely on whether the payment exceeds what that production would otherwise have earned. Ask a host or a programme administrator to break the total payment into these two components rather than quoting a single blended figure, because the blended number tells you nothing about how much of it required stopping.
Frequency and notice, the real cost drivers
The number that decides whether a programme makes sense for your fleet is not the per-event payment. It is how often events are called and how much notice you get before each one starts. A programme that pays well per event but is called rarely, with long notice, can be planned around and barely dents annual output. A programme that pays less per event but is called often, on short notice, forces the fleet into a pattern of frequent, unpredictable stops that is harder to plan production or maintenance around and harder to reconcile against your own metering afterwards.
Ask for the historical call frequency for the specific programme and the specific region, not an industry average, and ask what the typical notice period has been in practice rather than the contractual minimum. A programme that technically allows an hour of notice but has historically called with a full day's warning is a different proposition from one that regularly uses the minimum. Also ask about typical event duration, since a programme with frequent but very short events produces a different arithmetic than one with rare but long ones, even at the same total hours per year.
Lost production, the other side of the ledger
Every hour a fleet stops for a demand response event is an hour of production that would otherwise have run, and the margin on that production is the true cost of participating, not the notional value of the power not drawn. The comparison that matters is not the event payment against the site's power rate. It is the event payment against the margin the fleet would have earned in that hour: revenue at current hashprice minus the power cost you no longer pay.
This is also where the curtailment discussion and the demand response discussion overlap without being the same thing. A curtailment cap in a hosting agreement, of the kind covered in our piece on curtailment cost and caps, governs how much a host can reduce your load and under what billing terms. A demand response event may or may not count against that same cap depending on how the agreement defines curtailment, and that definition should be checked rather than assumed.
Splitting the payment, and what to ask before you sign
The load that stops when a demand response event is called is the hosted fleet, not an abstraction on the utility's books. That makes the split between host and hosted customer the question that decides whether participation pays from your side of the arrangement, independent of whether it pays from the host's side.
Ask these questions before assuming a programme benefits you at all:
- Which party is enrolled in the programme, the host under its own power agreement or an arrangement that explicitly names the hosted load?
- How is the payment split between host and customer, and is that split stated as a formula in the agreement rather than a discretionary arrangement?
- Does a demand response event count against any curtailment cap already in the contract, of the kind discussed alongside firm and interruptible power, or is it tracked separately?
- Are you notified of each event separately from a general curtailment notice, with its own timestamp and expected duration?
- Is there a running total you can request during the year, so the split is checkable as events accumulate rather than only at settlement?
These questions matter even when the host has done nothing wrong. A programme can be entirely legitimate and still leave you unable to verify your share of it if the agreement does not say how the split is calculated and reported. Find that clause before the first event happens, not after.
If your current agreement is silent on any of this, raise the silence directly rather than assuming it defaults in your favour. Our page on curtailment cost and caps sets out the adjacent clause that determines how much of your capacity you get in the first place, which is the number this whole calculation sits on top of. Our hosting rate page lists the curtailment questions to settle before two offers are compared.
