What is a fair usage policy?

A fair usage policy is the clause in your terms that defines what counts as reasonable consumption of the product, and what happens when a customer goes beyond it.

Think of fair usage as a guardrail in the contract - the mechanism that stops a single customer from running up cost the headline price doesn't capture.

We call this kind of guardrail a "risk fence." (It sits alongside two other guardrail types we use in pricing redesigns - segment fences for different customer types, commitment fences for different contract lengths - but those are separate conversations.)

Some pricing models - flat fees, seat licenses, anything labelled "unlimited" - decouple price from consumption. The headline price doesn't move when usage spikes. So you end up with one customer's heavy use creating real cost without any matching revenue, and the fair usage policy is what catches that.

Running with no usage limit at all - "a free plug to your house where they can drain all the electricity," as our CEO, Ulrik, likes to describe it - is the version of fair usage that doesn't work.

A generous limit is fine, and a customer asking for one is reasonable. A customer insisting on no cap at all is one of the few unambiguous warning signs you can spot in a SaaS contract.

Almost every SaaS company has a fair usage clause buried somewhere in its terms, and almost none of them treat it as a real commercial tool. That gap is what the rest of this guide is about

The three jobs of a fair usage policy

Across the pricing redesigns we've run, we see fair usage doing three quite different jobs. The first design decision is knowing which one your policy is doing, because a monetization threshold and a security cap call for very different limits and different enforcement.

1. A monetization threshold

In this version, the cap is really a paywall.

The metered thing is something you want customers using more of, so the limit isn't actually meant to stop them - it's an invitation to upgrade. "Up to 10 templates on Basic; unlimited on Advanced."

Customer goes to make the 11th, the system stops them and offers the upgrade. The whole point of this cap is to turn heavy use into expansion revenue.

2. A simplifier for a high-variance metric

Other times, the obvious metric has uncomfortable variance - some API calls are far larger than others, for example, and pricing each call the same way doesn't reflect that.

The cleanest move is usually to keep charging the simple unit (API calls) anyway and use the fair usage policy to normalize the outliers in the terms: any call over one second counts as two, over two seconds counts as three, and so on. The headline price stays simple to sell; the policy handles the edge cases in the contract.

3. A cost-and-security guardrail on usage that isn't tied to value

Sometimes the consumption you're metering isn't really about value at all - it's about cost or security risk (storage that nobody's reading, runaway API calls).

For this kind of usage, the policy is essentially just defining what "proper use" looks like ("up to 1,000 templates per user is reasonable") and protecting the system beyond that. You're not trying to monetize anything; you're just keeping the surface area sensible.

Designing a policy: cohort, measurement, threshold, break

Once you know which job your policy is doing, the rest of the design is fairly straightforward.

The design has four moving parts: who the policy applies to (cohort), what gets metered (measurement), where the line sits (threshold), and what happens when it's crossed (break):

Cohort - who it applies to

Not every customer should sit under the same limit. A new customer poking around in week one shouldn't be measured the same way as an enterprise account on a high annual contract or a legacy "unlimited" plan.

Each warrants different fair-usage logic, and each customer should sit in exactly one cohort at a time.

Treat new users gently - heavy early usage is often healthy onboarding. And separate genuinely bursty customers (campaign launches, month-end runs, seasonal spikes) from sustained overuse, because rigid daily caps harm healthy bursts. A pooled allowance over a rolling window handles bursts far better.

Measurement - what you count

The instinct is to count actions: prompts, generations, exports, model calls. That works at first and then runs into trouble - every new feature adds another limit, and soon there are twenty caps spread across every plan.

That sprawl is what we like to call fair-usage debt: the usage-limit cousin of commercial debt, where exceptions pile up until the system can't be explained or maintained.

The more durable approach, especially for AI, is to measure the underlying cost of a customer's total usage in one shared pool and set the fair-usage line against that dollar cost. Customers then use the product however creates value for them, while the business protects the economics with a single number.

‍Threshold - when something happens

‍Stage the thresholds rather than running a single cliff-edge. An early awareness point, a guidance point, then the line itself - so the experience feels like gradually applying the brakes, not slamming them.

Break - what actually happens when it's crossed

A break is whatever the system does when usage crosses the line. The pattern that works is gradual escalation: a notification first, a tightened policy if usage continues, hard enforcement only if it comes to that.

Where to set the limit

The rule we apply with most clients: set the fair-usage line at a level 95-98% of customers never touch.

The point of the policy is protection and the occasional commercial conversation. It isn't a toll for ordinary heavy users to pay.

The threshold should catch genuine outliers, and the "you've exceeded fair usage" discussion should stay rare.

For unlimited or flat models especially, always carry a fair usage clause in the terms as an ultimate backstop. It doesn't need to come up in the sale - it just needs to be there: language that says the business is entitled to throttle, slow, or charge if consumption hits an extreme.

The customer's legal team will find it; the explanation is that it's there for genuine outliers, and the conversation moves on. The aim is to make a runaway eight-figure infrastructure bill impossible by design, while keeping friction out of the sale.

Soft limits vs. hard limits

Where to set the line is one decision. How the line gets enforced is a separate one, and getting that wrong is often the bigger problem.

A hard block stops the customer at the limit - they cannot execute the 101st unit. It guarantees the system is never overused, but it's risky for anything business-critical.

If a customer can't process the payment or the request they depend on, the business has created an operational problem for them, and enterprise buyers will (rightly) insist on a guarantee that their solution runs. Hard-blocking value-driving usage is usually the wrong call.

A soft limit lets usage continue but fires an alert - to the customer, and to the customer-success team ("a customer is in breach; reach out").

CS then resolves it: is this a temporary spike, or do they need a bigger plan? Soft limits suit the usage the business wants customers to have.

The robust pattern is tranched soft-and-hard: a soft limit at the fair-usage line that triggers notifications and a monetization conversation, and a genuine hard limit far beyond it that protects the platform when one customer's load would harm everyone else's service.

The hard limit doesn't have to mean "shut off" - often the better move is to slow them down. Be lenient on minor, temporary overage (105 then back down is a non-event); act only on sustained overage.

The cost of an unenforced policy

How much is at stake when a fair usage policy isn't enforced? Take the European SaaS scale-up Ulrik discusses in the video below.

At around €30M ARR and 6,000 customers, the company had a fair usage clause in its terms - but no technical limit and nobody enforcing it. Customers ran past the stated limit and kept going, and the legal right to bill for the overage was never exercised.

In the prior 12 months alone, the company had the right to bill an additional €28M, close to doubling ARR, purely from the unenforced policy.

They chose not to back-bill (which would have triggered a churn event). Instead, the unenforced overage became proof of a viable pricing metric, and they used it to reprice the heaviest segments. A policy with no metering and no enforcement is the worst of both worlds - it neither protects the business nor monetizes anything.

Four common mistakes in fair usage design

A handful of patterns show up across the pricing redesigns we've run. The most common ones come down to how the policy gets built and run in practice, more than to which specific numbers end up in the terms.

Handling the few who overuse

What about the customers who blow past the line? They're a small group - usually under 5%. Within that 5%, some go extreme, running at 10x, 50x, or even 200x the fair-usage level.

That creates a trap: the business has the contractual right to bill them, but suddenly invoicing a customer 200 times the base for usage that was never flagged is a good way to lose them.

Our recommendation: own the gap instead of retroactively shocking the customer.

Reach out, acknowledge that the operational system wasn't in place to notify, slow, or invoice them, build that system, and then move them onto a more appropriate plan or reconfigure how they use the product so they're no longer in breach. Then go forward cleanly.

The unenforced overage is best treated as evidence - proof of a real, monetizable metric and a segment with far more willingness to pay than current pricing captures. That usually points toward a repricing opportunity (see SaaS Price Increases & Repricing [link when Hub-5 is live]). A back-bill is rarely the right move.

A couple of practical points sit alongside this.

Customers consistently want three things from any usage or credit model:

• The ability to measure what they've consumed
• Predict what they'll consume next
• And control who consumes and where the cap sits.

Giving them a dashboard, a forecast, and admin controls is increasingly the bar, and the companies that meet it win more deals. And enforcement needs to stay inside one consistent framework, because ad-hoc overage deals for individual accounts are how commercial debt accumulates.

Fair usage in AI products

Every query has a real per-unit cost, so an "unlimited" plan with a heavy user becomes an expensive customer to serve. That's why fair usage shows up as one of the three elements of margin-safe AI pricing. [link when Hub-6 is live].

AI products call for a different stance on overage. Our recommendation is generally to avoid penalties altogether - if a customer needs more, let them buy more at the same price (we'll even apply volume discounts retrospectively) to keep friction out of the sale.

The fair usage clause stays in the terms as the backstop for genuine extremes, with ordinary heavy use priced cleanly through the standard tiers. The trade is friction-free buying for the ordinary customer and a real cap on the few who go to extremes.