Всем привет. В статье разберём, как с помощью 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) — ключевые показатели эффективности процесса обработки инцидентов. Разработчики быстрее замечают проблему, быстрее находят её источник и быстрее выпускают исправление.

Путь к ошибке: зачем нужны «Breadcrumbs» во frontend-мониторинге