Open app

September 21, 2026

A usage metric now measures the step that multiplies rows and treats the steps after it as lookups, so you can sum a charge's amount while filtering on its payment intent — and the columns that would have given you a wrong total are no longer offered.

Measure one table, filter through another

Admin

A usage metric's path used to measure whatever table it ended on. That only made sense when every step multiplied rows. Add a step onto a table each row points at — a charge's payment intent — and you still have one row per charge, but the editor offered you the intent's columns to sum. Summing them adds an intent's amount once per charge against it: a number that looks reasonable and isn't.

The path now names the step it measures — the last one that multiplies — and treats the steps after it as lookups, joined so you can filter through them. The builder labels each step and says which table it is measuring.

So the thing you probably wanted works:

  • Step 1 — charges · charges.account_id → accounts.id. Measured.
  • Step 2 — payment_intents · charges.payment_intent_id → payment_intents.id. Lookup, filtered to live_mode is true.

Sum charges.amount. Test-mode charges drop out; the total is a sum of charge amounts.

Two smaller consequences. The Happened at and measure-column pickers now read the measured table, and adding a lookup step no longer resets the measure you already chose. And a lookup that could match more than one row is refused on save rather than quietly inflating every number — its join column has to be the primary key or carry a unique index.

On this page