my stripe meter reports 6% fewer events than my own counter, which number do i trust Usage-Based

Two causes, both boring, both in your chart.

The rejections are almost certainly fire-and-forget posts whose response nobody reads. Meter events have an accepted timestamp window; anything you replay from a backlog, a dead-letter drain or a late worker lands outside it and comes back a 400 that goes straight into the void. Log the status code and you will find them in an afternoon.

The dedupe is your retry wrapper. Stripe keeps one event per identifier and it is right to. Your table kept two because you inserted before you sent. Make the identifier deterministic - a hash of the task id, not a uuid generated at send time - and retries become free instead of lossy.

The structural fix is an outbox. Add metered_at and meter_event_id columns to the task row, a worker that fills them, and a query that finds rows older than an hour with metered_at is null. Then the gap is an alert on a Tuesday instead of a discovery at month end.

Trust the invoice, because that is the number your customer will argue with and the number your accountant will reconcile against the bank. Keep your own counter as the check, not the source.

Then set a threshold and treat crossing it as an incident. Anything over about half a percent means a bug, not variance. 6% is not a rounding difference, it is a broken pipe you have been paying for.

Meter aggregation is eventually consistent. Give it 24 hours and check again, the numbers usually converge and everyone stops panicking.

6% is not drift. Drift is 0.1%. I lost most of a week to something that looked exactly like this and it was a retry helper deduping on a key that included the attempt number, so every retry was a new event on our side and the same event on theirs. Look at your retry code before you look at anything else.

Worth knowing for the other direction too: if you ever bill an event you should not have, there is a meter event adjustment for cancelling it. You cannot just send a negative one and you cannot re-send a rejected one after the window closes, so build the retry to be fast rather than eventual.

For whatever it is worth, undercounting is the good direction to have this bug in. The other direction is refunds, a support thread and a customer who now reads every invoice line by line forever.