Usage-Based Pricing: How to Budget for a Bill Nobody Can Quote You

Per-seat pricing gives you a wrong number. Usage-based pricing gives you no number at all - and that is the harder problem. This is how to build a defensible forecast for a consumption bill, which six mechanics actually drive it, and the five questions to make a vendor answer in writing before the meter starts.

The short answer

You cannot get a quote for a usage-based product, so stop trying to get one and build a forecast instead. A defensible forecast has four parts: the unit the vendor actually meters, your own measured quantity of that unit over at least a few weeks, a multiplier for the waste you have not accounted for, and the tier breaks that make the cost curve bend.

Then you need four numbers rather than one: a floor, an expected case, a busy-month case, and a worst case produced by something going wrong rather than by success. The last of those is the one that ends careers and the one almost nobody calculates.

Finally, you need three contract terms in writing before the meter starts: whether failed and retried requests are billable, what happens at a spend cap, and how rates and tier definitions can change during the term and at renewal.

That is the whole method. The rest of this guide is each step in detail, the six mechanics that actually drive a consumption bill, and the specific questions to put in an email so the answers exist in writing rather than in a sales call. If you are buying a per-seat product instead, how to read a per-seat pricing page is the companion to this one.

Why this is a different problem from per-seat pricing

Per-seat pricing is a bad quote. Usage pricing is no quote at all, and the difference is structural rather than a matter of degree.

With per-seat pricing you control the quantity. You decide how many people get access, so the only genuine uncertainty is the rate per seat and the tier your feature requirements force you into. Both are published, both are stable for a term, and the arithmetic is one multiplication plus the costs hiding around the edges. The failure mode is underestimating headcount, which is a planning error you can bound.

With usage pricing the vendor controls the rate and your system controls the quantity. The rate is usually published and usually stable. The quantity is produced by your own product's behaviour, by your customers' behaviour, and sometimes by a defect nobody has found yet. You are not choosing a number; you are forecasting the output of a system you only partly understand.

That has two consequences worth internalising. First, the uncertainty is genuinely two-sided: a successful month costs more than a quiet one, so growth arrives as a bill. Second, the worst case is not set by your plans. A retry loop does not care about your forecast, and the mechanisms that protect you from it are contractual and operational rather than financial.

Step one: find the unit the vendor actually meters

Every consumption bill is a rate multiplied by a count, and almost every forecasting error starts with counting the wrong thing. The unit in the marketing copy and the unit in the billing documentation are frequently not the same unit, and only one of them appears on the invoice.

The pattern to watch for is a unit that sounds like a business event but is defined as a technical one. A product may talk about messages while billing per segment, so a long message is several billable units. It may talk about contacts while billing per contact per month, so the count is a stock rather than a flow and never goes down unless you actively delete. It may talk about documents while billing per page, per processed page, or per page per operation. It may talk about users while defining a user as anyone who authenticated in a calendar month, which includes people who logged in once by accident.

The discipline is to find the billing or metering page in the documentation rather than the pricing page, read the definition of the unit verbatim, and write it down in your own words. Then ask one question: what is the largest number of billable units a single real-world action by one of my users could produce? If the answer is more than one, you have found your first multiplier.

Step two: measure your own quantity before you forecast it

A forecast built from assumptions about your own volume is a guess wearing a spreadsheet. A forecast built from measurement is a forecast. The difference costs a few weeks and is the single highest-value step in this guide.

If the product has a free tier or a trial, run real traffic through it and read the vendor's own usage dashboard, because that is the meter that will bill you and it will not always agree with your logs. If you already have the data elsewhere - in your own logs, your database, your current provider's invoices - count it there, in the vendor's unit rather than in yours.

Measure for long enough to see your own periodicity. Most businesses have a weekly shape and a monthly shape, and many have a seasonal one. A week of data tells you about that week. Four weeks tells you about a month. A quarter tells you whether you have a trend, which is the thing that decides whether a commitment is sensible.

Record three numbers from the measurement rather than one: the quietest day, the median day, and the busiest day. The spread between the median and the busiest is a property of your business that will not go away, and it is what turns a single-number forecast into a range.

Step three: the six mechanics that actually drive the bill

These are the six places a consumption bill diverges from a naive forecast. All six are knowable in advance and none of them is hidden; they are simply in the billing documentation rather than on the pricing page.

First, tier breaks. Rates almost always step down with volume, and the steps are where the cost curve bends. A forecast that uses the headline rate at low volume overstates cost at scale, and one that uses the volume rate understates it badly at the start. Find the break points and calculate at each one.

Second, the minimum. Many consumption products have a platform fee, a minimum monthly commitment, or a minimum billable quantity per call. At low volume the minimum is the bill, and the rate is irrelevant.

Third, rounding. Per-second billing rounded up to the minute, per-kilobyte rounded up to the megabyte, per-page rounded up to a block: rounding is harmless at high volume per unit and brutal when your units are small and numerous.

Fourth, multi-dimensional metering. Many products bill two or three things at once - requests and storage and egress, or operations and retention. A forecast against one dimension is not a forecast.

Fifth, retries and duplicates, covered in its own section below because it deserves one.

Sixth, the free allowance, which is usually monthly and usually resets, and which makes small-volume testing misleadingly cheap.

Retries, duplicates and the waste multiplier

This is the mechanic that produces most of the genuinely shocking invoices, and it is the one least represented in forecasts, because forecasts are built from intentions and this is built from failure.

The principle is that almost nothing in a distributed integration guarantees that a useful action happens exactly once. A request times out and your client retries it. A webhook is delivered twice because the receiver acknowledged slowly. A sync job re-sends records it has already sent because the change-detection logic compares the wrong field. A queue is drained twice after a deploy. In every one of those cases a human did one thing and the meter counted more than one.

So the question to answer in writing is specific: are failed requests billable, are retried requests billable, and does the vendor deduplicate identical requests inside a window? The answers vary enormously, and a vendor who bills for failures has effectively made your error rate a line item.

The practical response is a waste multiplier applied to your measured quantity. Where you have measured your own retry and duplicate rate, use it. Where you have not, applying a deliberate uplift is more honest than applying none, and stating the uplift as an assumption in the forecast is what makes the forecast defensible when it turns out to be wrong.

Step four: build four numbers, not one

A single-number forecast for a variable cost is not a forecast, it is a wish. Build four, and label them so that nobody in the conversation can confuse them later.

The floor is your quietest realistic month, plus any minimum or platform fee. This is the number that matters for a committed-use discount, because a commitment above your floor is a bet rather than a saving.

The expected case is your measured median multiplied out to a month, with the waste multiplier applied and the correct tier rate for that volume. This is the number for the budget.

The busy case is your measured busiest period extrapolated as though it were the whole month. This is the number for the person who has to approve the budget, because it is the one that will actually arrive in a good month and it is often startlingly higher than the expected case.

The failure case is the one almost nobody builds, and it is not produced by growth. It is produced by a retry loop, a duplicated job, a misconfigured integration, or a customer sending you ten times their normal traffic. Estimate it by asking what your system could emit in a month if a common failure went unnoticed for a week. Then look at whether a spend cap would have stopped it. Usually that is the only thing that would have.

Step five: caps, alerts and the outage trade-off

Once you have a failure case, the next question is what stands between that number and your invoice. There are only three mechanisms and you need to know which ones you have before you need them.

A hard spend cap stops billing by stopping service. It bounds the financial damage absolutely, and in a production system it converts a billing incident into an outage. That may be the right trade for an internal tool and the wrong one for a customer-facing path, and the decision belongs to whoever owns the service rather than to whoever owns the budget.

A soft cap or budget alert notifies somebody and keeps billing. It bounds nothing by itself; it buys response time, and response time is only useful if the alert reaches a human who can act at the hour it fires. An alert routed to an unmonitored inbox is decoration.

Rate limits on your own side are the third mechanism and the most reliable, because they do not depend on the vendor. A client-side limit on how many calls per minute your own system is permitted to make caps the worst case regardless of what the vendor offers.

Ask three things in writing: what happens at the cap, who is notified and through what channel, and how fast the cap can be raised during an incident. The last one decides whether a hard cap is survivable.

Step six: the contract terms that decide whether the bill can change

The rate you forecast against is only as stable as the contract that holds it, and consumption products are repriced more often than per-seat products because the vendor's own costs move.

Four terms are worth reading before the feature list. How much notice is required to change a published rate, and does the notice period apply to existing customers or only to new ones? Can tier definitions change independently of rates, which is the quieter way to raise a bill without raising a price? What is the renewal mechanism, and specifically does it roll over automatically at the then-current rate card? And is there any protection against reclassification, where a unit you were billed for in one category moves into a more expensive one.

The second thing to look for is the direction of any commitment. A committed-use discount trades price for certainty, and the certainty is the vendor's rather than yours: they get a guaranteed floor and you get a discount on volume you may not reach. That trade is good once you have real data and the commitment sits below your measured floor. It is bad in month one, which is exactly when it is most often offered, because at that point your floor is a guess and the commitment converts a variable cost into a fixed one at your moment of maximum uncertainty.

When the vendor will not publish rates

Some consumption products publish a full rate card. Some publish the first tier and route the rest to sales. Some publish nothing. The right response to each is different and none of them is to estimate.

This site says contact sales and does not guess, because a guessed rate presented in a comparison is a fabricated figure dressed as a measurement, and it misleads in a way that no caveat repairs. Apply the same rule to your own evaluation: an unpriced product is a product you cannot compare, and it should sit outside the comparison until a number exists.

To get that number, make the request specific and make it written. State your measured volume in the vendor's own unit, state the dimensions you need priced, and ask for the tier breaks, the treatment of failures and retries, the minimum, and the renewal terms in the same document. A vendor who answers that in writing has given you something you can put in a comparison. A vendor who answers it only verbally has given you nothing, and the gap between the call and the invoice is where the disagreement will happen.

If a vendor will not put numbers in writing during an evaluation, that is information rather than an obstacle. It tells you what the renewal conversation will be like, when you have less leverage than you do today.

A worked method, without a single vendor rate

Here is the whole thing as a sequence, deliberately with no numbers in it, so that it works on any vendor's page on any day.

Read the billing documentation and write down the metered unit in your own words. Establish the maximum number of billable units one real user action can produce. Find the tier breaks, the minimum, the rounding rule and every dimension that is metered separately.

Measure your own volume in that unit, for at least four weeks, from the vendor's meter if one is available and from your own data if not. Record the quietest day, the median day and the busiest day.

Measure or estimate your retry and duplicate rate, and write it down as a stated assumption rather than folding it silently into the total.

Calculate four monthly numbers: floor, expected, busy and failure. Use the tier rate appropriate to each volume rather than one rate for all four.

Decide what stands between the failure number and the invoice: a hard cap, a soft cap plus a monitored alert, a client-side rate limit, or nothing.

Get the four contract terms in writing. Then, and only then, compare against the alternative - including the per-seat alternative if one exists, using the method in how to read a per-seat pricing page.

The checklist, in order

What exactly is the metered unit, as defined in the billing documentation rather than the pricing page?

How many billable units can one real user action produce at most?

What are the tier breaks, and what is the rate inside each one?

Is there a minimum - a platform fee, a monthly commitment, or a minimum billable quantity per call?

What is the rounding rule, and how much does it matter at my unit size?

How many dimensions are metered separately, and have I forecast all of them?

What is the free allowance, does it reset, and is my testing inside it?

Are failed requests billable? Are retries? Does the vendor deduplicate?

What is my measured volume, over how many weeks, from which meter?

What is my measured or assumed waste multiplier, and is it written down as an assumption?

What are my four numbers: floor, expected, busy, failure?

What happens at a spend cap - stop service or keep billing - and who is notified?

Do I have a client-side rate limit that bounds the failure case without depending on the vendor?

How much notice is required to change rates, and can tier definitions change separately?

What is the renewal mechanism, and at whose rate card?

If a commitment is offered, is it below my measured floor, and do I have a quarter of data?

If no rate is published, do I have one in writing at my stated volume - or is this product still outside the comparison?

How we chose

This guide is method rather than measurement, for the same reason as the rest of this site: a price is only true on the day it was verified, and a usage rate without a dated source is worse than no rate at all. So there are no vendor rates here. What there is instead is the structure that consumption pricing shares across vendors, the arithmetic to run against your own numbers, and the specific contract terms that decide whether a bill can surprise you. Where a vendor publishes rates only through sales, this site says contact sales and does not estimate - and the same rule applies to you during an evaluation.

Frequently asked