Stripe metered billing aggregation: sum vs max vs last_ever explained
Explains Stripe meter aggregation formulas sum, max, and last_ever. Use when choosing how meter events roll up into a billable amount. Not for reporting events or debugging zeros.
TL;DR
sum adds every event value in the period (total API calls), max takes the highest single value (peak concurrent seats), and last_ever takes the most recent value (current seat count). Pick the formula that matches what you actually sell; the wrong one bills nonsense. You set it on the meter, and it applies at every period close.
Steps
Define what the customer buys: cumulative consumption, peak usage, or current level. Expected: The business metric is named before the formula.
Cumulative (API calls, GB transferred): choose sum. Expected: The invoice totals all events in the period.
Peak (max concurrent connections): choose max. Expected: The invoice bills the highest observed value.
Current level (seats right now): choose last_ever. Expected: The invoice bills the latest reported value.
Sanity-check with sample events on the meter dashboard before the first real invoice. Expected: The formula behaves as expected on your data shape.
When to use
- You create a meter and must pick an aggregation
- Usage bills look wrong for the business model
- You compare sum vs max vs last_ever
When not to use
- Events are missing entirely (debug the pipeline)
- You need tiered or graduated pricing (price tiers, separate concern)
- Values need averaging (average is not a meter formula; pre-aggregate)
Compatibility
Stripe Billing Meters; aggregation set at meter creation. Formulas: sum, max, last_ever (and count variants).
Variant phrasings
### Stripe meter aggregation formula choose
### sum vs max meter Stripe billing
### last_ever meter meaning
Root cause
Meters store raw events and compute at close, so the formula is the entire pricing semantic: sum treats each event as additive work, max treats events as samples of a level, last_ever treats them as state updates. There is no universal default because the same event stream means three different products.
Edge cases
- Changing the formula mid-stream does not rewrite past periods; it applies going forward
- last_ever with sparse events bills stale values; ensure regular heartbeats
- max over a long period can surprise customers after one spike; consider shorter periods
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_IHa94za5h8aMURFAlmwfiw