Как увидеть ошибки консоли у ваших пользователей без DevTools

сетевые запросыDenis Povarov30 августа 2026 г.

Где-то в вашем инструменте поддержки лежит шаблон ответа: «Не могли бы вы нажать F12, открыть вкладку „Консоль“ и прислать нам скриншот всего, что написано красным?» Его отправляют несколько раз в неделю. Почти никогда в ответ не приходит ничего полезного, а каждое исправление, которое от него зависело, стоит днями, пока переписка затухает.

Ниже — как отказаться от этого шаблона. Учить пользователей DevTools не нужно: достаточно, чтобы в следующий раз, когда пользователь напишет «страница сломалась», ошибки консоли и упавшие запросы из его сессии уже лежали в отчёте.

Почему просьба открыть DevTools не срабатывает

Шаблон не работает по причинам, которые никак не связаны с доброй волей пользователя:

Большинство пользователей никогда не видели DevTools. Сочетание клавиш зависит от системы и браузера, вкладка «Консоль» — одна из десятка, а красные стеки вызовов выглядят как шум. Вы просите человека поработать с профессиональным инструментом — один раз, без присмотра, по переписке.

Доказательств уже нет. Вывод консоли живёт ровно столько, сколько открыта вкладка. Когда приходит ваш ответ, пользователь уже закрыл страницу, и нужной вам ошибки больше нигде нет. Теперь вы просите его воспроизвести баг по заказу — то есть сделать то, чего не можете сами.

Скриншот — неподходящий формат. Даже в лучшем случае вы получаете картинку со свёрнутым стеком вызовов, обрезанную так, что единственная важная строка не попала в кадр, без меток времени и без сетевого контекста. По ней нельзя искать, её нельзя развернуть и не с чем сопоставить.

Сложите все круги переписки, и окажется, что просьба открыть DevTools стоит дней ожидания, а приносит в лучшем случае малую часть того, что браузер бесплатно знал в момент сбоя.

Поменяйте направление: сообщает браузер, пользователь только описывает

Решение — перестать пропускать доказательства через память и скриншоты пользователя и брать их там, где они уже есть: в его браузере, в момент бага.

Именно это делает виджет для баг-репортов. Когда BugDump установлен, сбор данных идёт ещё до того, как что-то сломалось: пока пользователь ходит по сайту, SDK держит скользящее окно последних записей консоли и сетевой активности. Наткнувшись на проблему, пользователь нажимает кнопку бага и пишет одно предложение своими словами. Это предложение — вся его работа. Всё, о чём вы иначе попросили бы, прикладывается автоматически:

Логи консоли — последние 300 записей с отмеченными ошибками и предупреждениями, с поиском в BugDump. Непойманные исключения и необработанные отклонения промисов тоже собираются, в том числе те, которые ваш код никогда не логировал.
Сетевые запросы — последние 150, с методом, кодом ответа и временем; сбои подсвечены. Ответ 500, который предшествовал видимой поломке, лежит прямо рядом с ней.
Окружение — браузер, ОС, устройство, вьюпорт и точный URL страницы, так что вопрос «каким браузером вы пользуетесь?» больше никто не печатает.
Воспроизведение сессии — запись того, что пользователь делал до отчёта, которую можно перематывать, — для багов, где причина в последовательности кликов.

Всё держится на порядке событий. Любой процесс, который начинает собирать данные после того, как пользователь решил сообщить о баге, уже пропустил ошибку. Буферы работают постоянно, поэтому момент сбоя попадает в отчёт, хотя никто — и меньше всех пользователь — не знал, что сейчас случится баг.

Как читать отчёт: диагноз за две минуты

Отчёт с приложенной телеметрией читают в определённом порядке, и это быстро:

Прочитайте предложение пользователя — оно говорит о его намерении («я пытался оплатить»).
Перейдите к отмеченным записям — непойманному исключению в консоли и упавшему запросу в списке сети.
Посмотрите, что случилось прямо перед ними: запрос, который вернул неожиданные данные, предупреждение на предыдущем действии.
Если важна последовательность, перемотайте воспроизведение и посмотрите, что именно нажимал пользователь.

Ошибка консоли называет симптом в вашем коде, сетевой лог обычно называет причину, а воспроизведение снимает споры о том, что значит «я просто нажал как обычно». Большинство отчётов проходят путь от «открыл» до «знаю, какой файл открыть» без единого сообщения пользователю — уточняющей переписки, которая раньше занимала дни, просто не бывает.

Настройка

Установка — одна строка на любом сайте, без сборки и без адаптера под фреймворк:

<script src="https://bugdump.com/sdk/latest.js" async data-api-key="your-api-key"></script>

В первый же день стоит добавить две вещи. Если пользователи входят в ваше приложение под своим аккаунтом, вызовите bugdump('identify', { email }) после входа, чтобы у каждого отчёта был автор. А если на страницах работают болтливые сторонние скрипты — маячки аналитики, опрос фича-флагов, — задайте в SDK consoleFilter и networkFilter, чтобы в буферах оставалась активность вашего приложения, а не фоновый шум. Отфильтрованные записи никогда не покидают браузер, так что фильтры не только наводят порядок, но и защищают приватность. Тела запросов и ответов по умолчанию не собираются (их включает captureNetworkBodies); не включайте их без конкретной причины и укажите в политике конфиденциальности, что баг-репорты содержат диагностические логи.

Потом проверьте всю цепочку: отправьте отчёт со своего сайта, откройте его в BugDump и убедитесь, что панели консоли и сети показывают вашу сессию. За эти две минуты вы пройдёте ровно тот путь, который пройдут ваши пользователи.

Отправьте шаблон на пенсию

Шаблон ответа не исчезнет совсем — он станет короче. «Не могли бы вы нажать на странице кнопку бага и отправить отчёт?» — просьба в одну строку, которую пользователь действительно может выполнить, а в ответ приходит не обрезанный скриншот, а консоль, сетевой лог, окружение и воспроизведение сессии из момента, когда всё сломалось.

Читать ошибки вы по-прежнему будете каждый день, только в BugDump и из тех браузеров, где баги и случились, — вместо того чтобы просить пользователей описать красный текст, который им и не нужно было понимать.