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
Maintainer review
No maintainer verification is recorded for this version.
This records the version a maintainer checked. It does not assert that the version is the latest upstream release.