Schedule Trigger у n8n не працює після оновлення

Сценарій у списку зелений, GET /api/v1/workflows/{id} повертає "active": true, у Schedule Trigger заданий коректний cron, помилок у розділі Executions немає — але й самих виконань немає. Ручний запуск працює. Вебхуки в тому самому сценарії працюють. Не працює лише розклад.

#Що відбувається насправді

Коли сценарій оновлюють програмно, найпростіший варіант здається очевидним: вимкнути, залити нову версію, увімкнути назад. Приблизно так:

curl -X POST "$BASE/api/v1/workflows/$ID/deactivate" -H "X-N8N-API-KEY: $KEY"
curl -X PUT  "$BASE/api/v1/workflows/$ID" -H "X-N8N-API-KEY: $KEY" \
     -H 'Content-Type: application/json' --data @workflow.json
curl -X POST "$BASE/api/v1/workflows/$ID/activate" -H "X-N8N-API-KEY: $KEY"

Усі три запити повертають 200. Останній повертає об’єкт сценарію з "active": true. З погляду API операція виконана.

Проте тригер розкладу в n8n — це не прапорець у базі даних, а зареєстроване завдання в планувальнику процесу. Активація через публічний API виставляє прапорець, але не завжди відновлює цю реєстрацію. Стан у базі й стан у планувальнику розходяться, і ззовні цього розходження не видно ніде: ні в списку сценаріїв, ні у відповіді API, ні в логах.

#Як оновлювати сценарій правильно

Заливайте нову версію одним запитом PUT безпосередньо в активний сценарій, нічого не вимикаючи:

curl -X PUT "$BASE/api/v1/workflows/$ID" \
     -H "X-N8N-API-KEY: $KEY" \
     -H 'Content-Type: application/json' \
     --data @workflow.json

Ось чому це працює. У публічному API поле active доступне лише для читання — воно не входить у тіло запиту PUT, і запит його не змінює. Отже, оновлення активного сценарію не скидає його стан: він лишається активним. Зміну розкладу планувальник підхоплює самостійно.

Ми це перевірили: залили в активний сценарій новий розклад і дочекались спрацювання у призначену хвилину, без деактивації.

#Як перевірити, що розклад зареєстровано

Прапорець active нічого не підтверджує. Єдине підтвердження — факт виконання. Найпростіша перевірка — поставити розклад на найближчу хвилину, дочекатись її та переглянути список виконань:

# найближча хвилина у cron Schedule Trigger, залити PUT-ом, зачекати,
# потім перевірити, чи з’явилось виконання типу trigger
curl -s "$BASE/api/v1/executions?workflowId=$ID&limit=5" \
     -H "X-N8N-API-KEY: $KEY" \
  | jq -r '.data[] | "\(.id)  \(.mode)  \(.status)  \(.startedAt)"'

Дивитися потрібно саме на поле mode. Ручний запуск дає manual, вебхук — webhook, і лише розклад дає trigger. Якщо після оновлення в списку є тільки manual, розклад не зареєстровано — хоч би скільки разів API відповідав active: true.

#Що робити, якщо розклад уже не працює

Стан планувальника відновлює перемикач Active в інтерфейсі: вимкніть його вручну й увімкніть назад. Це руйнує ідею автоматичної заливки, але як разова процедура працює. Після цього переходьте на PUT без деактивації, і ситуація більше не повториться.

Перезапуск самого процесу n8n також відновлює реєстрацію, оскільки під час старту n8n наново читає розклади з бази даних. Якщо у вас Docker і перезапуск обходиться дешево, це швидше, ніж шукати потрібний сценарій у списку.

#Чому PUT зручний для згенерованих сценаріїв

Запит PUT замінює сценарій цілком, разом з ідентифікаторами нод. Якщо ви генеруєте JSON скриптом і id нод щоразу випадкові, кожна заливка перебудовує зв’язки і показує зміни там, де нічого не змінилось.

Щоб цього не сталося, id ноди роблять детермінованим — хешем від назви. Тоді повторна заливка не руйнує зв’язки і показує тільки справжні зміни. Як це влаштовано, розібрано окремо: n8n-сценарії в коді.

Разом це дає робочий цикл: правка в генераторі → PUT → перевірка виконань. Без деактивації і без ручних дій в інтерфейсі.

#Висновки

Послідовність deactivate + activate через публічний API повертає 200 і active: true, але розклад після цього може лишитися незареєстрованим.
Оновлюйте активний сценарій одним запитом PUT — поле active у публічному API все одно доступне лише для читання.
Перевіряйте не прапорець, а наявність виконання з mode: trigger.
Реєстрацію відновлюють перемикачем Active в інтерфейсі або перезапуском процесу.
Детерміновані id нод роблять повторну заливку безпечною.

#Часті запитання

#Чи можна оновлювати активний сценарій через API без деактивації?

Так. Поле active у публічному API доступне лише для читання, тому запит PUT не змінює стан сценарію. Він лишається активним, а планувальник підхоплює нове значення розкладу самостійно.

#Чому API повертає active: true, якщо розклад не працює?

Прапорець active зберігається в базі даних, а за розклад відповідає зареєстроване завдання в планувальнику процесу. Це два різні стани, і після активації через API вони можуть розійтися. Відповідь API показує лише перший із них.

#Як швидко перевірити, що тригер зареєстровано?

Поставте розклад на найближчу хвилину, дочекайтесь її та перегляньте GET /api/v1/executions. Якщо виконання з mode: trigger не з’явилось, тригер не зареєстровано.

#Джерела

n8n Public API — Workflow — опис методів і полів, зокрема того, що active не редагується через API
n8n Docs — Schedule Trigger — як влаштовано тригер розкладу
Взято з власного досвіду

Schedule Trigger у n8n: чому розклад не спрацьовує після оновлення