Sentry не ловит ваши баги, если вы неправильно размечаете события

Sentry не ловит ваши баги, если вы неправильно размечаете события

Sentry часто ставят как “пожарную сигнализацию”, но без дисциплины он быстро превращается в шумный логгер. Для арб-команд это особенно больно: один и тот же сбой на лендинге, в трекере или в webhook’е может плодить сотни дублей и скрывать реальную причину.

Что настраивать в первую очередь:
— до отправки ошибок приводите контекст к одному формату: user_id, campaign_id, route, provider;
— фильтруйте ожидаемые исключения и сетевые таймауты, которые уже обработаны в коде;
— группируйте события по стабильному fingerprint, а не по тексту сообщения;
— отмечайте уровень критичности: crash, degraded, warning, иначе alerting быстро выгорает.

Полезнее всего Sentry работает вместе с трассировкой запросов: виден путь от клика до падения, а не только стек. Для лендингов и API это помогает быстро понять, где ломается цепочка — на фронте, в бэке, в прокси или в интеграции с внешним сервисом.

Если Sentry молчит, это не всегда хорошо: проверьте, что ошибки реально отправляются, а не отбрасываются фильтрами. А если он шумит — сначала режьте дубли и мусор, потом уже добавляйте алерты.