Всем привет. В статье разберём, как с помощью open-source трекера ошибок Хоук восстанавливать цепочку событий перед ошибкой и быстрее понимать, что именно привело к сбою в приложении.

Представим обычную ситуацию: пользователь пишет в поддержку, что нажимает «Оплатить», но ничего не происходит. В мониторинге при этом есть ошибка. Видно, где она произошла в коде, виден URL страницы, браузер, устройство и окружение. Но открытым остается вопрос: что именно пользователь делал перед ошибкой?

Он сразу нажал «Оплатить»? До этого менял способ доставки? Обновлял страницу? Нажал кнопку несколько раз? Был ли перед ошибкой неудачный запрос к API? Без этой последовательности расследование часто превращается в угадывание: ошибка есть, но путь к ней не виден.

В чём проблема обычного расследования

Стек-трейс отвечает на вопрос «где произошла ошибка», а Breadcrumbs — на вопрос «как приложение к ней пришло». Именно эта информация помогает быстрее находить и устранять причины сбоев.

Например, в событии может быть видно:

• страница: /checkout,

• ошибка в обработчике оплаты,

• браузер пользователя,

• время возникновения ошибки.

Но при этом может быть непонятно:

• с какой страницы пользователь пришёл,

• был ли перед этим запрос на расчёт стоимости,

• успешно ли сохранился адрес доставки,

• какой именно сценарий привёл к падению.

Получается ситуация: мы видим саму ошибку, но не видим путь к ней. Именно эту проблему решают «хлебные крошки».

Что такое Breadcrumbs

Breadcrumbs – это цепочка событий, которые произошли перед ошибкой.

В неё могут попадать:

• переходы между страницами,

• клики пользователя,

• сетевые запросы,

• ответы API,

• события из бизнес-логики,

• важные состояния интерфейса.

Вместо одиночного сообщения «что-то сломалось на checkout» команда получает последовательность действий, которая к этому привела.

Как это выглядит на практике

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

• navigation: /cart → /checkout

• 200 GET /api/checkout/order

• ui: click "Сохранить адрес"

• 400 POST /api/checkout/address

• ui: click "Оплатить"

• logic: payment step submitted

• logic: payment create skipped — address not saved

• error: Payment failed

Здесь и кроется причина проблемы: заказ загрузился нормально, но при сохранении адреса доставки возникла 400 ошибка, и интерфейс не заблокировал кнопку «Оплатить». Пользователь дошёл до оплаты с неполным заказом, из-за чего упала ошибка в обработчике платежа.

Корень проблемы не в кнопке «Оплатить», а раньше: адрес доставки не сохранился, а UI не отреагировал на ошибку API. Breadcrumbs показывают, где сценарий пошёл не туда – ещё до финальной ошибки.

Что собирается автоматически

Событий браузера, которые записываются в хлебные крошки:

• переходы между страницами,

• клики по элементам,

• fetch/XHR-запросы,

• базовую информацию о браузере и окружении.

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

Что стоит добавлять вручную

Мониторинг может зафиксировать клик по кнопке, но не знает, что для вашей системы этот клик означает переход к оплате, подтверждение доставки или отправку формы. Поэтому в важных местах стоит добавлять свои Breadcrumbs:

• переход между шагами формы,

• отправку заказа,

• выбор тарифа,

• применение промокода,

• успешное сохранение адреса,

• начало оплаты,

• получение ответа от платёжного сервиса.

Например:

hawk.breadcrumbs.add({
  timestamp: Date.now(),
  type: "logic",
  category: "checkout.step",
  level: "info",
  message: "Пользователь перешёл к оплате",
  data: {
    step: "payment",
    orderId: order.id,
  },
});

Или для запроса:

hawk.breadcrumbs.add({
  timestamp: Date.now(),
  type: "request",
  category: "fetch",
  level: "error",
  message: "POST /api/checkout/address 400",
  data: {
    method: "POST",
    url: "/api/checkout/address",
    status: 400,
    reason: "address_validation_failed",
  },
});

Такие события делают расследование понятнее: команда видит не просто техническую цепочку, а осмысленный сценарий.

Хлебные крошки на бэкенде

Breadcrumbs помогают показывать последовательность операций и на стороне сервера.

Например:

• Вызов методов API

• Запросы в базу данных

• Обращения к внешним сервисам

• Обращения к доменному уровню

• Парсинг и обработку данных

• Кастомную логику

Как правило, фрагменты хлебных крошек на бэкенде проставляются руками с помощью метода breadcrumbs.add().

Что в итоге

Breadcrumbs не заменяют информацию об ошибке, а добавляют к ней контекст. Сама ошибка отвечает на вопрос: где что-то сломалось. Breadcrumbs помогают ответить на другой вопрос: как пользователь до этого дошёл.

Для команды это означает меньше догадок, меньше ручного воспроизведения и более короткий путь от алерта до исправления бага. Breadcrumbs помогают быстрее выявлять и понимать причины ошибок, сокращая как MTTD (Mean Time to Detect), так и MTTR (Mean Time to Resolve) — ключевые показатели эффективности процесса обработки инцидентов. Разработчики быстрее замечают проблему, быстрее находят её источник и быстрее выпускают исправление.