Failed charges that never got retried. Canceled customers you’re still serving for free. Paste a read-only key and get the number in ~60 seconds.
Create one in Stripe → restricted keys, read-only. It’s used once, server-side, then thrown away.
0 subscriptions are failing silently — charges bouncing, access still on.
No failing subscriptions right now. Clean — this time. The leaks start the next time a card bounces.
None of these throw an error. Stripe keeps a failing subscription around, your app keeps the lights on, and the revenue just… stops. The audit counts the exact dollars.
A card bounces, the subscription goes past_due, and it sits there. Dunning tools chase the charge — they don’t tell you how much is bleeding right now.
The subscription is unpaid or canceled in Stripe, but your app never got the memo and keeps the account live. Free service, on your tab.
A missed webhook and the two drift apart — active here, gone there. the paid product reconciles Stripe ↔ your database; the free audit flags it from Stripe alone.
The whole point is to be safe enough that connecting a key is a non-decision.
You create a restricted key with read permissions only. It can’t move money, change data, or create anything.
The key goes to one function, reads your subscriptions, computes the number, and is discarded. It’s never written to a database or a log.
Only the dollar figure and the count come back. No customer data leaves Stripe.
A one-time number is a wake-up call. The leak comes back every time a card fails. $49/mo watches it continuously and pings you when the figure moves.