Monitoring Stripe webhook ingestion with StillOnline
Stripe can be healthy while your webhook receiver is broken. In that case, payments may succeed, but your app may fail to provision, update subscriptions, or mark invoices as paid.
Monitor the receiver as its own production component. It is often the difference between “payments work” and “customers are confused.”
Quick answer
Use StillOnline to monitor a safe health URL near your Stripe webhook receiver and expose a Payments or Billing webhooks component on the status page. Stripe documents webhook delivery and retries in Stripe webhooks, and its public health is visible on Stripe status. StillOnline can alert owners through email, Telegram, or Slack with Free = one channel and Pro/Ultimate = all three on pricing. Do not make the uptime check create a real payment or replay production events.
What to check
Your uptime check should prove the receiver path is alive without sending fake financial events.
| Layer | Check | Status component |
|---|---|---|
| Receiver process | GET /health/webhooks | Billing webhooks |
| Queue | lightweight queue health | Background jobs |
| Database write | read-only dependency check | Billing data |
| Stripe itself | official Stripe status | Third-party dependency |
Incident wording
Separate checkout from post-payment processing. If Stripe checkout is working but your receiver is delayed, say that clearly.
Example: “Payments may complete, but subscription activation and invoice status updates are delayed. We are processing queued Stripe webhook events.”
Retries and recovery
Stripe retries webhook delivery, but your app still needs idempotent handlers. Monitor the receiver, then use logs and Stripe’s event view to confirm whether events are queued, failed, or already replayed.
When Stripe or another vendor is involved, use the same dependency framing as in third-party status: Stripe, Auth0, SendGrid: name the upstream provider and keep your component labels precise.
Related guides
- Third-party status: Stripe, Auth0, SendGrid
- Webhook ingestion endpoint monitoring
- Monitoring background workers and queues
- Public status page guide
FAQ
Can StillOnline monitor Stripe directly?
Use Stripe’s official status page for Stripe availability. Use StillOnline to monitor your own webhook receiver and billing-adjacent backend paths.
Should the uptime check send a real Stripe webhook event?
No. Use a safe health endpoint near the receiver. Real event replay belongs in operational tooling, not periodic uptime checks.
What component should I show on the StillOnline status page?
Use Payments, Billing webhooks, or Checkout depending on what customers understand. If only webhook processing is delayed, do not label the whole app as down.
How should I alert the owner about Stripe webhook ingestion?
Use a direct StillOnline owner channel first. Slack or Telegram works for fast response; email is useful for routing into on-call or automation tools.