Why it happens
Usually one of three things: a traffic drop (a campaign ended, a link broke, a listing moved), a checkout step that degraded for some customers (a slow 3-D Secure, one card type declining), or a real lull. Occasionally it is the first sign of a failure that has not finished happening.
How to tell
- Hourly payments below the hour-of-week baseline for consecutive hours, with no failed journey to explain it.
- Checkout still passes; Stripe still delivers events.
- Sometimes a rise in payment_failed events for one card type or one country.
The fix
- Open Stripe › Payments, filter the window, and read the decline codes on the failed attempts.
- Run your own checkout end to end on a phone, including the 3-D Secure step.
- Look at where visitors came from in the window; a dropped source explains most quiet hours.
- If it persists into a second day, treat it as an incident and look for what changed.
The prompt for your builder
Paste this into Lovable, Bolt, Cursor, Claude Code or whatever built the app. Replace anything in capitals. It never asks you to paste a secret into a chat; keys go into your host’s environment, by you.
Add a small internal page to my app that shows, for the last 48 hours, hourly counts of checkouts started, payments completed and payments failed with their Stripe decline codes, so I can tell a quiet hour with fewer visitors from a step that started failing.
How Keelnest catches it
Revenue Guard raises this as an estimated incident — labelled estimated, never as lost revenue — when the hourly count stays below baseline, and it says so when the evidence is weak and nothing else corroborates it.
Know the moment this happens.
Keelnest watches your production app every five minutes and tells you in plain English what broke — with the fix. Free for your first app.