Unit economics: cost per request is the metric that matters

Here’s a bill that went up 15% last month. Is that bad? You can’t answer — not from the total. If traffic doubled, a 15% cost increase is a triumph. If traffic was flat, it’s a leak. The monthly number, the one everyone stares at, is missing the only thing that makes it meaningful: the denominator.

Unit economics is the fix. Instead of “what did we spend,” you ask “what did it cost to serve one unit of the thing we actually do” — a request, a tenant, a transaction, a GB processed. That single shift changes cost from an accounting fact into an engineering signal.

Why the total lies

A raw cost trend conflates two completely different stories: your efficiency and your growth. A rising bill on rising traffic can mean you’re getting more efficient per unit even as you spend more in total. A flat bill on falling traffic means you’re quietly getting worse. The total can’t tell them apart, so teams optimize against a number that’s structurally ambiguous.

Cost per request separates them. Now a spike is unmissable: cost-per-request jumped 30% overnight, traffic didn’t, something regressed — go find it. That’s an alert you can act on, not a quarterly surprise.

Building the denominator

You need two things joined: cost, allocated to a service, and a business throughput metric for that service. The second is the part most teams already have and never connect to the first — requests from the load balancer, jobs from the queue, active tenants from the app. The join is what’s usually missing, because cost lives in one system and throughput in another and nobody owns the seam.

Start coarse. Even a rough cost-per-request at the service level, trended weekly, beats a perfectly-attributed monthly total. Precision can come later; the denominator has to come first.

What it unlocks

Once cost has a unit, a lot of previously-fuzzy decisions get sharp:

• Regressions become visible — a deploy that doubles per-request cost shows up the next day, not the next invoice.
• Rightsizing gets a target — you’re not chasing “cheaper,” you’re chasing a cost-per-unit budget.
• Business conversations get honest — “this feature costs 4 cents per call” is a product decision anyone can reason about; “infra was $80k” is not.

Transparency is the whole point

None of this works without joining two worlds that don’t normally talk: your billing data and your utilization and throughput signals. Keep them separate and you’re stuck reading totals and guessing. Join them and every service has a unit price you can watch, budget, and defend.

That join is exactly what Lizrd is built to make continuous — it reads your cost and utilization together, allocates spend to services, and puts it in the units your business already measures, so a per-request regression is something you catch on Tuesday instead of explaining at the end of the month. The total tells you what you spent. Unit economics tells you whether it was worth it.