The bill went up 18% last month.
Somebody will ask why. Somebody else will pull up a chart. And the conversation will go straight to which service grew, which namespace moved, which team forgot to turn something off.
All useful questions. But they skip the first one: did the business grow too?
If orders went up 25% and spend went up 18%, each order got cheaper. That is a good month, and the chart that started the panic is evidence of it. If orders were flat, the same 18% is a real problem. The bill alone cannot tell you which month you had.
The number that answers it
A unit cost is spend divided by something the business counts.
| Spend | Divided by | Gives you |
|---|---|---|
| Checkout team | Orders | Cost per order |
| Whole organisation | Active customers | Cost per customer |
| Search workloads | Search requests | Cost per thousand searches |
| AI coding agent spend in one repository | Merged pull requests | Cost per merged PR |
The idea is old. What stops most teams is the plumbing: getting the right slice of spend on top, getting the right count underneath, and keeping both honest month after month.
Pick the top half carefully
Dividing the whole bill by orders is a start, but it hides more than it shows. Your data platform does not scale with checkout volume. Your staging clusters do not either.
In CostOptix a metric can divide one of three things:
- The whole organisation. Everything counted once, across cloud, Kubernetes, hosts and AI agents.
- One team. Whatever that team owns on the Ownership page, including its share of idle cluster and host capacity.
- Specific spend. A hand-picked set: some namespaces, a few host services, a cloud service or resource group, or AI usage in particular repositories.
Specific spend is the one most people end up using. It lets you divide only the checkout workloads by orders, without reorganising your teams or starting a tagging project to get there.
Get the bottom half without a project
The count underneath can come from wherever you already have it:
- typed in by hand for monthly figures,
- uploaded as a CSV,
- pushed daily from your own systems through the API,
- or, for revenue, imported from Stripe.
The Stripe import uses net sales and a restricted, read-only key. It only imports in the currency your costs are in, because a cost per dollar of revenue that quietly mixes currencies is worse than no number at all.
Make the number trustworthy
A unit cost that changes after you have reported it is a unit cost nobody will quote twice. So a closed month can be locked. If a figure underneath it is corrected later, the change is versioned and you can see what it was before.
You can also set a target, say $0.05 per order, and get a webhook when a unit cost moves, so the number reaches the people who own it without anyone opening a dashboard.
What it changes
Once unit costs are in place, the monthly review gets a different first question. Not "why did spend go up?" but "did spend go up faster than the thing it pays for?"
Most months the answer is no, and the review gets shorter. In the months where it is yes, you know the increase is real before anyone opens a chart, and Ownership tells you who can act on it.