Sentry спасает не от багов, а от слепых мест в проде

Sentry спасает не от багов, а от слепых мест в проде

Если подключить его «на всякий случай», через неделю в проекте будет шум, а не сигнал. Рабочая схема такая: сначала ловите ошибки на границе входа — API, формы, фоновые задачи, webhook-и. Потом добавляете breadcrumbs, чтобы видеть цепочку действий перед падением.

Главная настройка — не сбор всего подряд, а фильтрация. Отсекайте известные ошибки, health-check, шум от ботов и то, что уже чините. Иначе алерты быстро перестают читать. Для фронта отдельно проверьте source maps, для бэка — маскирование персональных данных и понятные теги по окружению, версии и типу запроса.

Не менее важны релизы: без них Sentry показывает «где сломалось», но плохо отвечает на вопрос «после какого изменения». Связывайте ошибки с деплоем, а не с календарём. Для команд это экономит часы на поиске виноватого и делает triage коротким.

Если у вас мало времени, настройте три вещи: один канал алертов, один набор игнор-правил и один обязательный тег для каждого события. Этого уже хватает, чтобы Sentry стал инструментом, а не складом красных уведомлений.