A bill you don't have to fear

Monitoring vendors have taught a generation of engineers to fear their own success. Autoscale for a sale and the bill remembers. Migrate a fleet over a weekend and the peak becomes the price. Whole conference talks exist about tuning your observability spend, which is a polite way of saying the pricing punishes you for using the product.

We wrote our billing rules as if they were security rules, because they protect the same asset: trust. Here they are, with the reasoning attached.

The average, not the peak

Usage is snapshotted daily and the invoice is computed on the month's average. Spin up fifty extra hosts for a two-day migration and the math barely moves; a high-watermark model would have charged the month as if the migration never ended. Peaks are what infrastructure is for. A bill that punishes peaks is a bill that argues against using your own capacity, and we would rather our customers migrate bravely.

Count what the customer can point at

Every billable unit must be something you can see in the console as a card or a row. This sounds obvious and is not: our own containers axis briefly counted stopped container groups and hypervisor guests that only exist as inventory, and the number on the usage bar disagreed with anything you could count on screen. A customer caught it before it ever hit an invoice, which is one customer too many. The axis was fixed to count running groups only, and the rule was written down: if the number on the bill cannot be reconciled by eye against the UI, the number is wrong even when it is technically defensible.

The same rule decides the weird cases. A 48-port switch is one device, not 48 sensors. A dense box hosting four hundred sites bills by sites, because that is where the value visibly lives, and the folded list of exactly which sites count is one click away. Ephemeral containers group by service and image, never per instance, so autoscaling changes your capacity and not your bill.

Paid features are opt-in, per unit, with the price on the button

Deep tracing is priced per site. The tempting implementation is host-wide: flip APM on, every site with traffic becomes billable, invoice explains it later. We shipped the opposite. Enabling instrumentation on a host only reveals candidates; each site is enabled by an explicit click, and if that site would exceed the plan's included quota, the button itself says what it will cost per month before you press it.

Nothing appears on an invoice that was not individually, knowingly clicked. The test we use: a finance person auditing the bill should be able to trace every line to a deliberate human action, not to a side effect of traffic.

Overage is linear, visible, and never a trap

Cross your quota and the extra units bill at a published per-unit price, warned about loudly and long before the boundary. We deliberately did not add automatic plan upgrades or silent caps: nobody's subscription quietly changes shape because a counter moved. Sustained overage can genuinely cost more than the next plan, and the console will say so plainly, but the decision to change plans belongs to a human. Predictability is not the absence of cost. It is the absence of surprise.

Why write this down publicly

Because billing mechanics are architecture, and architecture is easier to trust when the reasoning is inspectable. Every rule above constrains us, not you: the average forgives your migrations, the visibility rule forces our counters to survive an eyeball audit, the opt-in rule slows down our own revenue on purpose. A pricing model is a long conversation with your customers about whether you can be left alone with their credit card. We intend to keep passing it.