Skip to main content
Tenderly может уведомлять вас по email, когда Web3 Action не выполняется. Поскольку Web3 Actions часто являются частью критически важных рабочих процессов, email-уведомления позволяют быстро реагировать, когда Action перестаёт работать, не отслеживая Tenderly Dashboard.
Overview of the existing Web3 Actions

Обзор существующих Web3 Actions

Теперь вы можете настроить email в качестве назначения, куда будете получать уведомления Tenderly о неудачных выполнениях ваших Web3 Actions, кликнув на любой Action:
Information about a specific Web3 Action

Информация о конкретном Web3 Action

Прокрутите вниз до раздела Destinations:
Choosing an email destination for Web3 Action notifications

Выбор email-назначения для уведомлений Web3 Action

У нас уже настроено несколько email-назначений. Мы можем включать и выключать их, чтобы не удалять определённые каналы доставки email в периоды, когда мы не хотим их использовать. Чтобы добавить новый канал доставки email, просто нажмите кнопку Add Destination Email в правом нижнем углу, введите email, который вы хотите использовать, и всё. Вам нужно будет подтвердить email и включить переключатель для этого email после верификации. Также можно выбрать несколько email в качестве каналов доставки для одного Action. Если вы добавляете email, который уже используете в качестве email аккаунта, или если вы добавили этот email через какой-то другой процесс в Tenderly (например, через Alerts), ваш email будет распознан, и вам не придётся верифицировать его снова.
Adding a new email address

Добавление нового email-адреса

Вы также можете выбирать каналы доставки email-уведомлений при создании нового action. Однако если вы хотите добавить новый email в качестве назначения, вам нужно сначала сделать это, а затем выбрать его как опцию в процессе создания нового action (Create New Action).
Choosing an email destination upon creating a Web3 Action

Выбор email-назначения при создании Web3 Action

Когда отправляются письма о сбоях

Tenderly группирует неудачные выполнения в инциденты, вместо того чтобы отправлять письмо о каждом сбое. Когда выполнение завершается ошибкой, сбой сопоставляется с инцидентом по версии Action и ошибке. Вы получаете письмо только при создании нового инцидента, то есть когда данная ошибка возникает впервые для текущей версии вашего Action. Пока инцидент открыт, повторные возникновения той же ошибки группируются под ним и не вызывают дополнительных писем. Инциденты никогда не разрешаются автоматически, даже если последующие выполнения успешны. Управляйте ими в Error Reporting, где статус инцидента управляет уведомлениями:
  • Подтверждение (Acknowledge) инцидента оставляет уведомления об этой ошибке отключёнными.
  • Разрешение (Resolve) инцидента снова включает уведомления: если та же ошибка возникнет снова, будет создан новый инцидент и вы получите новое письмо.
Публикация новой версии Action также сбрасывает группировку: первый сбой новой версии создаёт новый инцидент и вызывает отправку письма. Письма о сбоях охватывают выполнения, запущенные триггером и завершившиеся ошибкой. Ручные запуски никогда не отправляют письма о сбоях и не создают инциденты, независимо от результата, поэтому для проверки пути уведомлений используйте запуск по триггеру. Выполнения, которые превысили время ожидания или были ограничены по частоте, также не вызывают писем о сбоях.