Выбирайте расписание, если работа должна начинаться в определённое время, и событийный запуск, если нужен ответ на действие внешней системы. При сбое сначала выясните, был ли запуск, затем проверьте полученные данные и только после этого — действие. Повторное создание Zap редко помогает понять, на какой границе возникла проблема.
Выберите инструкцию под свою задачу. Ниже — подробный разбор выбора и проверки результата.
вводный материал о запуске по времени. Старые названия элементов интерфейса не заменяют проверку текущей настройки и часового пояса рабочего пространства.
Читать материалпример получения данных от внешнего источника. Полезен, когда исходная система сама сообщает о событии.
Читать материалмаршрут от сообщения об ошибке к проверке настроек и входных полей. Используйте для конкретного выполнения, а не для абстрактного «ничего не работает».
Читать материалПри плановой работе добавьте в контрольный результат понятное обозначение периода. По нему получатель сможет отличить запоздавший запуск от свежего отчёта. При событийной работе сохраните признак исходного события. Обе меры помогают обсуждать конкретное выполнение, даже когда два результата внешне выглядят одинаково.
| Требование | Что рассмотреть | Первое испытание |
|---|---|---|
| Подготовить итог к заданному времени | Расписание | Совпали ли ожидаемый момент и фактический запуск |
| Обработать событие внешнего сервиса | Webhook | Пришёл ли запрос с нужными полями |
| Разобрать уже возникшую ошибку | Историю конкретного выполнения | Какой шаг первым получил неверный результат |
Плановый запуск ещё не определяет, какие записи надо обработать. Для ежедневной сводки отдельно задайте период данных. Событийный запуск тоже не доказывает полноту сведений: уведомление может содержать только идентификатор записи. Поэтому опишите два ожидания: когда начинается работа и что процесс должен знать в этот момент.
Например, итог за вчера и список новых заявок за последние сутки могут различаться по границам периода. Назовите ожидаемый промежуток явно и проверьте его на нескольких записях около границы. Если проблема связана с отбором данных, смена расписания на webhook сама по себе не исправит расчёт результата.
Если запуска нет, сравните ожидаемое событие с фактом у источника. Для расписания уточните момент, в который работа должна начаться. Для webhook проверьте отправку и адрес назначения. Пока вход не подтверждён, нет смысла менять текст письма или настройки последнего действия цепочки.
Если запуск есть, найдите первый шаг с неожиданным результатом. Сверьте наличие обязательных полей, их тип и фактическое значение. Например, пустой адрес получателя — проблема данных до отправки письма. А корректный адрес при отказе внешнего сервиса требует другого разбора. Не объединяйте эти ситуации в одну общую ошибку.
Перед повтором выясните, успела ли часть действий выполниться. Иначе исправление последнего шага может сопровождаться повторной записью данных или лишним письмом. Ожидаемое поведение повторного запуска лучше проверить на тестовом получателе и небольшой записи, которую легко найти в истории.
После изменения повторите тот же пример, на котором возник сбой. Если он проходит, добавьте ещё обычный случай. Это даст основание считать конкретную причину устранённой и сохранит понятный пример для будущего сопровождения.
