Мониторинг Stripe webhook ingestion в StillOnline
Stripe может работать, а ваш webhook receiver — нет. Тогда платежи проходят, но приложение не выдаёт доступ, не обновляет подписку или не отмечает invoice как paid.
Мониторьте receiver как отдельный production-компонент. Часто это разница между «payments work» и «customers are confused».
Краткий ответ
Используйте StillOnline для безопасного health URL рядом со Stripe webhook receiver и покажите компонент Payments или Billing webhooks на странице статуса. Stripe описывает доставку и retries в Stripe webhooks, а публичное состояние сервиса видно на Stripe status. StillOnline будит владельца через email, Telegram или Slack: Free = один канал, Pro/Ultimate = все три на тарифах. Не делайте uptime check, который создаёт реальный payment или replay production events.
Что проверять
Проверка должна доказывать, что путь receiver жив, но не отправлять фейковые финансовые события.
| Слой | Проверка | Компонент статуса |
|---|---|---|
| Receiver process | GET /health/webhooks | Billing webhooks |
| Queue | лёгкий health очереди | Background jobs |
| Database write | read-only dependency check | Billing data |
| Сам Stripe | official Stripe status | Third-party dependency |
Текст инцидента
Разделяйте checkout и post-payment processing. Если Stripe checkout работает, но receiver задерживается, так и пишите.
Пример: “Payments may complete, but subscription activation and invoice status updates are delayed. We are processing queued Stripe webhook events.”
Retries и восстановление
Stripe повторяет доставку webhooks, но вашему приложению всё равно нужны idempotent handlers. StillOnline мониторит receiver, а логи и Stripe event view показывают, queued, failed или replayed события.
Если в сбое участвует Stripe или другой поставщик, используйте тот же подход, что в third-party status: Stripe, Auth0, SendGrid: назовите upstream и держите компоненты точными.
FAQ
StillOnline может мониторить Stripe напрямую?
Для доступности Stripe используйте официальную страницу статуса Stripe. StillOnline должен мониторить ваш webhook receiver и billing-adjacent backend paths.
Uptime check должен отправлять реальный Stripe webhook event?
Нет. Используйте безопасный health endpoint рядом с receiver. Replay реальных событий — задача operational tooling, а не периодической uptime-проверки.
Какой компонент показать на странице статуса StillOnline?
Payments, Billing webhooks или Checkout — выберите то, что понятно клиенту. Если задержан только webhook processing, не называйте всё приложение down.
Как будить владельца при проблеме Stripe webhook ingestion?
Сначала прямой owner channel StillOnline. Slack или Telegram подходят для быстрой реакции, email удобен для маршрутизации в on-call или автоматизацию.
Дополнительно
Сторонние сервисы: Stripe, Auth0, SendGrid на странице статуса
Когда Stripe, Auth0 или SendGrid лежат, а ваш API отвечает 200: как пометить degraded third-party на странице StillOnline без ложной «нашей» аварии.
Мониторинг endpoint приёма webhooks
Мониторинг /webhooks/*: 200 vs 401, проверка подписи и чем HTTP-проверки StillOnline отличаются от публичного REST API.
Мониторинг фоновых workers и очередей
Веб зелёный, задачи нет: heartbeat URL, прокси глубины очереди и отдельные components на странице статуса StillOnline.
Публичная страница статуса для SaaS
Как получить публичную страницу статуса: uptime, история и инциденты для клиентов. SaaS, API, Telegram-бот, AI на VPS — бесплатный старт в StillOnline.