Ежедневный отчёт о трендах на базе n8n: тестируем планировщик 2.45

Воркфлоу n8n на собственном сервере может собирать ежедневный отчёт о трендах на основе данных EveryInfra за $0,002224 за запуск. Сложности возникают не с вызовами API. Первая — запуски, запланированное время которых приходится на период простоя n8n. Вторая — повторные запуски, при которых может казаться, что списание произошло дважды. Третья — один неудачный вызов, способный остановить весь отчёт.

26 октября 2026 года с 10:36 до 11:25 по сингапурскому времени (SGT, UTC+8; 02:36–03:25 UTC) мы запускали n8n 2.45.3 на Mac каждые 3 минуты. Дважды мы намеренно его останавливали. Затем мы сверили 14 отчётов с базой данных, метриками и логами нашего сервера.

В этой статье «ежедневный отчёт о трендах» — это воркфлоу n8n на вашей собственной машине. Его запускает нода Schedule Trigger. Нода Code перечисляет списки трендов, которые нужно прочитать. Нода HTTP Request вызывает EveryInfra с одним API-ключом. Вторая нода Code записывает в Markdown-файл топ-10 каждого списка, пересечение с прошлым запуском и стоимость.

Отчёт показывает, о чём люди говорят этим утром. Он не предсказывает будущие тренды и не проверяет достоверность обсуждаемых тем.

Иллюстрация показывает принцип работы персистентного планировщика (durable scheduler). Запуск — это не таймер внутри процесса, а строка в базе данных, созданная до запланированного времени. Когда это время наступает, один из процессов n8n захватывает строку и выполняет запуск. Документация n8n делит этот процесс на пять стадий: материализация, выполнение, восстановление, хранение и сверка владельца. В каждом описанном ниже тесте мы считывали из SQLite реальные строки, относящиеся к этим стадиям.

Как выглядит один отчёт

Это отчёт запуска в 10:39:24 SGT. Исходный файл создала первая версия шага 5, которая также присвоила номер одному рекламному слоту Weibo. Мы пересобрали отчёт из сырых ответов этого запуска с помощью исправленного шага 5 (сортировка по rank, пропуск строк без ранга). Для краткости мы удалили часть строк из списков.

# EveryInfra daily report 2026-10-26T10:39:24.294+08:00

## X US trends (52 items, $0.000556)
1. Lula
2. Brazil
3. Mahomes
4. Chiefs

## X Mexico trends (71 items, $0.000556)
1. Lula
2. Pachuca
3. #EleccionesBrasil2026

## Weibo hot search (10 items, 2 promoted slots skipped, $0.000556)
4. Brazil's President Lula wins re-election

## Deliberately misspelled list name: failed (HTTP 422, invalid_value)
- `boards` must be one of: challenge, entertainment, hotspot, seeding, social (got 'hot')

## Cost of this run
- Sum of charged_usd in the responses: $0.002224
- Actual charge after removing replays: $0.002224

Заголовки на китайском, потому что наша команда писала воркфлоу на китайском. Подписи — это свободный текст в ноде Code, поэтому их можно заменить на английские одной строкой. На две вещи в этом файле стоит посмотреть внимательнее.

Во-первых, одно событие одновременно возглавило четыре списка. 25 октября в Бразилии прошёл второй тур президентских выборов (уведомление Высшего избирательного суда). В 10:39 SGT следующего дня (25 октября, 22:39 по нью-йоркскому времени) «Lula» был на 1-м месте в трендах X для США и для Мексики. Та же новость стояла на 4-м месте в горячем поиске Weibo и на 5-м месте в списке горячих тем Douyin в Китае. Ранг в Weibo требует пояснения. Четвёртой строкой ответа Weibo была брендовая кампания без поля rank, то есть рекламный слот (правила горячего поиска Weibo называют коммерческую рекламу одним из типов меток). У строки про Лулу был rank 4. Наша первая нода отчёта нумеровала строки по позиции, поэтому поставила Лулу на 5-е место и включила рекламу в горячие темы. Теперь шаг 5 сортирует по rank, пропускает строки с пустым рангом и указывает в заголовке, сколько строк пропущено. Отчёт по нескольким платформам показывает такие пересечения с одного взгляда. Американские тренды в то же время заняты спортом: «Mahomes», «Chiefs» и «Packers» заполняют остальную часть топ-10 США.

Во-вторых, неудачный вызов не сорвал отчёт. В отчёте он показан короткой заметкой с причиной и предложенным значением. В разделе стоимости указано, что ошибка ничего не стоила. Тест 4 объясняет, почему такое поведение нужно продумать до первой ошибки, а не после неё.

Критерии прохождения, которые мы записали до первого запуска

До первого запуска мы записали в файл проверок 10 критериев прохождения. Увидев результаты, мы их не меняли. Было только одно исключение. Мы планировали проверять списания по балансу аккаунта. В 10:33 SGT мы обнаружили, что тот же тестовый ключ используют другие авторы, поэтому баланс меняется и из-за их вызовов. Ещё до первого вызова со списанием мы изменили проверку: теперь мы ищем каждый request_id в серверном журнале вызовов.

Самые сложные проблемы с задачами по расписанию не выглядят как ошибки: запуск пропал, запуск произошёл дважды или списанная сумма немного выше ожидаемой. Поэтому в проверках заранее указывают число запусков, строки и стоимость. Один пользователь n8n писал о нодах, которые получают ноль элементов. Следующие ноды не запускаются, но выполнение всё равно показывает «Success», а воркфлоу обработки ошибок так и не стартует (ветка Reddit r/n8n). Такие проблемы можно найти, только если заранее зафиксировать ожидаемое число запусков, набор строк и стоимость.

Перед началом: версия, способ установки и Node.js

Версия. Персистентный планировщик включён по умолчанию начиная с n8n 2.45.0, выпущенной 20 октября 2026 года. В истории изменений сказано, что ноды Schedule Trigger «теперь по умолчанию работают с персистентным планировщиком». Но 26 октября в реестре npm под тегом latest всё ещё была версия 2.44.6 (22 октября). Версия 2.45.3 (23 октября) была под тегами next и beta. Поэтому обычная команда npm install n8n сегодня установит 2.44.6, где персистентный планировщик по умолчанию ещё выключен. Чтобы повторить этот тест, укажите версию явно.

Кроме того, n8n выпускает патчи для двух линеек отдельно. В обновлении безопасности от 14 октября сказано: «beta исправлена в v2.44.1» и «stable исправлена в v2.43.5».

С 13 по 23 октября для линеек 2.44 и 2.45 в npm вышло в общей сложности 7 версий (от 2.44.0 до 2.45.3), причём патчи поочерёдно выходили в обеих линейках. Если установить «последнюю версию» по инструкции из интернета, можно получить любую из этих двух линеек.

Способ установки. Мы использовали npm, потому что на этом Mac есть Node.js, но нет Docker. У этого выбора есть два ограничения, о которых нужно знать. Первое: на странице установки через npm сказано, что с n8n 3.0 установка через npm объявлена устаревшей. На странице несовместимых изменений 3.0 сказано, что для версии 3.0 требуется Docker и что запускаемого пакета n8n в npm не будет. Руководство разработчика n8n на GitHub относит выход v3 примерно к октябрю 2026 года. Установленный у нас n8n при запуске также вывел предупреждение: «Running n8n outside a container is deprecated».

Так что npm подходит для теста на ноутбуке. Для отчёта, который должен работать каждый день много месяцев, используйте Docker Compose или установку одной командой.

Во-вторых, объём. При чистой установке было добавлено 2 328 пакетов за 6 минут, а каталог node_modules занял 4,4 ГБ. Первая установка прервалась посередине. При последующем запуске из папки с незавершённой установкой возникла ошибка Cannot find module 'kuler'. Повторный npm install в той же папке не помог.

Мы удалили node_modules и package-lock.json, установили всё заново, и n8n запустился. Если установка прервалась, начните заново с пустой папки. Так быстрее всего.

Версия Node.js. Документация и пакет здесь расходятся. Страница установки через npm указывает диапазон «от 20.19 до 24.x». Сам пакет (npm view n8n@'2.45.3' engines) требует >=24.0.0. Таблица релизов Node.js показывает, что поддержка версии 20 закончилась в марте 2026 года, 24 — это LTS, а 26 — «Current». Мы использовали 26.11.1 и в этом тесте проблем не заметили. Но эта версия вне задокументированного диапазона, поэтому для отчёта, который работает долго, используйте Node.js 24 LTS.

Есть ещё одна ловушка: порт. Сначала мы настроили n8n на порт 5679. n8n сразу остановился, оставив в логе одну строку: «n8n Task Broker's port 5679 is already in use». В n8n 2.x узлы Code выполняет встроенный обработчик задач, брокер которого по умолчанию использует порт 5679. Мы изменили N8N_PORT на 5690 и задали для N8N_RUNNERS_BROKER_PORT значение 5691.

После этого n8n запустился. Вот все настройки, которые мы использовали:

export N8N_USER_FOLDER=$HOME/Downloads/n8n-lf25/home      # database and encryption key live here
export N8N_PORT=5690 N8N_LISTEN_ADDRESS=127.0.0.1          # listen on this machine only
export N8N_RUNNERS_BROKER_PORT=5691                        # keep away from the broker default 5679
export GENERIC_TIMEZONE=Asia/Singapore TZ=Asia/Singapore   # the default is America/New_York
export N8N_RESTRICT_FILE_ACCESS_TO=$HOME/Downloads/n8n-lf25/reports
export N8N_DIAGNOSTICS_ENABLED=false N8N_VERSION_NOTIFICATIONS_ENABLED=false
export N8N_METRICS=true N8N_METRICS_INCLUDE_SCHEDULER_METRICS=true
npm install n8n@2.45.3 --no-audit --no-fund

Те же настройки в виде таблицы с пояснениями к каждой из них:

Адрес прослушивания задан как 127.0.0.1, поэтому открыть n8n можно только с этой машины. В годовом отчёте от 14 октября компания Censys, занимающаяся сканированием интернета, насчитала 113 926 доступных из интернета хостов n8n. Из тех хостов, версию которых удалось определить, 76 % имели хотя бы одну недавнюю критическую уязвимость (блог Censys). n8n также выпускает обновления безопасности каждые две недели (например, обновление от 1 октября). Чтобы читать отчёты с другой машины, синхронизируйте папку reports/. Не выставляйте редактор n8n в открытый доступ в интернете.

Не пропускайте строку с часовым поясом. На странице о часовом поясе сказано, что экземпляр на собственном сервере по умолчанию использует America/New_York. Schedule Trigger ориентируется на этот пояс, определяя, что именно означает «8 утра». Для пользователя в Нью-Йорке значение по умолчанию оказывается правильным лишь по совпадению. У всех остальных отчёт на 8 утра

запускается не в тот час. Часовой пояс можно также задать для каждого воркфлоу в его настройках. Мы указали Asia/Singapore в обоих местах.

Строка с настройкой доступа к файлам тоже важна. Начиная с n8n 2.0, узел Read/Write Files по умолчанию может работать только с ~/.n8n-files. Чтобы сохранять отчёты в другом месте, необходимо разрешить доступ к нужной папке с помощью N8N_RESTRICT_FILE_ACCESS_TO. Разрешите доступ только к этой папке.

Читателям из США: подготовьтесь к 1 ноября

Если ваш отчёт работает по американскому времени, обратите внимание на одну дату. По данным NIST, в 2026 году летнее время заканчивается 1 ноября в 2:00 по местному времени, и час с 1:00 повторяется. Ежедневному отчёту в 8 утра по

America/New_York ничего не грозит. 8:00 далеко от времени перевода часов, а персистентный планировщик сохраняет заданное местное время запуска. С задачей, назначенной на 1:30 ночи, всё иначе, потому что 1 ноября это время наступает дважды.

В этой таблице показан переход 1 ноября для основных часовых поясов США по правилам NIST:

В документации персистентного планировщика сказано, что почасовые, ежедневные, еженедельные и ежемесячные расписания срабатывают как раньше «при обычном использовании». Там же сказано, что персистентный планировщик корректнее обрабатывает переходы на летнее время и обратно, високосные годы и 53-ю неделю, чем планировщик, работающий в памяти: последний «мог ошибаться на один период». Реальный перевод часов мы не проверяли, поскольку он произойдёт только на следующей неделе. Наш совет прост: не назначайте ежедневный отчёт на время между 1:00

и 3:00 по местному времени. Укажите для воркфлоу реальный идентификатор часового пояса IANA, например America/Chicago, а не фиксированное смещение. Эти идентификаторы и соответствующие им правила хранятся в базе часовых поясов IANA.

Собираем воркфлоу: шесть узлов, по одному действию на шаг

В воркфлоу шесть узлов. Анимация показывает один запуск.

Мы не собирали этот воркфлоу вручную в редакторе. Мы описали его в JSON и импортировали через командную строку n8n. У этого два плюса. Каждый шаг можно точно повторить. Кроме того, в локальном n8n не нужна учётная запись владельца. Для каждого шага мы приводим действие, ожидаемый результат и причину.

1. Сохраните API-ключ как учётные данные n8n. Выполните jq -n --arg t "$EVERYINFRA_API_KEY" '[{"id":"eiBearer000001","name":"EveryInfra API Key","type":"httpBearerAuth","data":{"token":$t}}]' | n8n import:credentials --input=/dev/stdin. Должно появиться сообщение «Successfully imported 1 credential».

Главное здесь — --input=/dev/stdin. Ключ передаётся только через переменную окружения и конвейер, не попадая в файл. Если поле data содержит открытый текст, команда импорта шифрует его ключом экземпляра перед сохранением записи (в исходном коде это cipher.encryptV2). Не вводите ключ в поле заголовка узла HTTP Request.

Иначе он открытым текстом попадёт в JSON воркфлоу, в каждый экспорт и в историю версий. На странице учётных данных HTTP Request перечислены Bearer, Header и другие типы. Выберите Bearer. Он отправляет заголовок Authorization: Bearer из RFC 6750 — именно в таком формате его ждёт EveryInfra.

1. Добавьте Schedule Trigger. Для теста укажите «каждые 3 минуты». Для ежедневного запуска выберите «Days», укажите час 8 и минуту 0. После публикации в таблице SQLite scheduled_job появится новая запись: intervalSeconds — 180, misfirePolicy — skip, misfireGraceSeconds — 60.

На странице Schedule Trigger описаны две новые настройки узла. У «If Execution Is Missed» три варианта, по умолчанию запуск пропускается. «Missed Execution Grace Period (Seconds)» при значении 0 берёт значение экземпляра N8N_SCHEDULER_MISFIRE_GRACE, по умолчанию 60 секунд. Обе настройки действуют только для узлов, добавленных в версии 2.36 или позже, и только при включённом персистентном планировщике. Сохраняемые значения мы взяли из исходного кода узла: coalesce_owner — это «Run the Most Recent Missed Execution», coalesce — то же для каждого правила, skip — значение по умолчанию.

1. Перечислите запросы в узле Code, с отдельным ключом для каждого запроса. Узел возвращает 5 записей. В каждой есть платформа, действие, параметры и поле idem. В данных запуска должно быть 5 выходных записей.

const now = DateTime.now().setZone('Asia/Singapore');
// Daily use: one key per day (a rerun on the same day is a replay). Test: one key per minute.
const KEY_BY = 'day';
const keyBase = KEY_BY === 'day' ? now.toFormat('yyyyLLdd') : now.toFormat('yyyyLLdd-HHmm');
const reqs = [
  { label: 'Weibo hot search', platform: 'weibo', action: 'trending', params: {} },
  { label: 'Douyin hot list', platform: 'douyin', action: 'trending', params: { boards: 'hotspot' } },
  { label: 'X US trends', platform: 'twitter', action: 'trending', params: { country: 'us' } },
  { label: 'X Mexico trends', platform: 'twitter', action: 'trending', params: { country: 'mx' } },
  { label: 'Misspelled list name', platform: 'douyin', action: 'trending', params: { boards: 'hot' } },
];
return reqs.map(r => ({ json: { ...r,
  idem: `daily-report-${keyBase}-${r.platform}-${r.params.country || r.params.boards || 'default'}`,
  firedAt: now.toISO() } }));

Вот код, который мы запускали, без изменений. Подписи на китайском, потому что наша команда читает отчёты на китайском; строки подписей можно менять как угодно.

Зачем формировать ключ самостоятельно? Ежедневный отчёт не должен запускаться дважды за один день, приводить к двойному списанию и создавать два разных файла. В описании OpenAPI EveryInfra сказано, что синхронный вызов с тем же Idempotency-Key, платформой, действием и параметрами в течение 24 часов «повторно возвращает первый успешный ответ». Вызов не выполняется и не оплачивается повторно. Если параметры другие, а ключ тот же, возвращается 409 idempotency_conflict.

Ключ на основе даты говорит API: «одна копия сегодняшнего списка». Этот подход соответствует черновику IETF Idempotency-Key header, который 22 октября 2026 года обновился до версии 08. В тесте мы задали KEY_BY значение minute. С одним ключом на день каждый тестовый запуск раз в 3 минуты после первого был бы повтором, и мы не увидели бы, как меняются списки.

1. Вызовите EveryInfra через узел HTTP Request. Укажите метод POST и URL https://api.everyinfra.com/api/v1/social. Выберите учётные данные Bearer из шага 1. Добавьте заголовок Idempotency-Key: {{ $json.idem }}. Передайте тело запроса в формате JSON: {{ JSON.stringify({ platform: $json.platform, action: $json.action, params: $json.params }) }}. Включите «Include Response Headers and Status» и «Never Error». Настройте пакетную обработку: 1 запись в пакете и 1 500 мс между пакетами. За один запуск должно получиться 5 записей: 4 со statusCode 200 и 1 с 422.

«Never Error» — самый важный переключатель на этом шаге. На странице HTTP Request сказано, что по умолчанию ответ не из диапазона 2xx приводит к ошибке узла. Запуск на этом останавливается, и узел отчёта не выполняется. Ежедневному отчёту нужно обратное. Если один список не получен, остальные всё равно попадают в отчёт, а для неудачного списка добавляется понятная пометка.

С «Never Error» и полным ответом тело и статус 422 передаются следующему узлу как обычные данные. Интервал между пакетами удерживает вас в пределах лимита EveryInfra: 10 вызовов в минуту на ключ. GET /api/v1/account возвращает это значение в поле key_requests_per_minute. При интервале 1,5 секунды между вызовами один запуск занимал примерно 13–16 секунд.

1. Сформируйте отчёт во втором узле Code и сохраните данные прошлого запуска. Этот узел по порядку сопоставляет 5 ответов с 5 запросами из шага 3. Он берёт топ-10 каждого списка по rank и пропускает рекламные записи без места (см. код ниже). Он читает прошлый топ-10 из $getWorkflowStaticData('global'), считает пересечение и сохраняет новые списки. На выходе должна быть одна запись с markdown и fileName.

Шаг с топ-10 стоит отладить отдельно. В ответ по горячим темам Weibo подмешаны рекламные позиции. У них есть заголовок и значение популярности, но нет rank. За наши 14 запусков рекламные позиции заняли в сумме 16 из первых 10 мест на Weibo; у Douyin и X их не было. Если нумеровать по позиции, реклама становится горячей темой, а все места после неё сдвигаются на одно. Поместите во второй узел Code такое правило: если хотя бы у одной записи списка есть rank, оставляйте только записи с rank и сортируйте по нему; нумеруйте по позиции, только если rank нет ни у одной записи.

function top10(results) {
  const rows = results || [];
  const hasRank = rows.some(x => x.rank != null);
  const kept = hasRank ? rows.filter(x => x.rank != null).sort((a, b) => a.rank - b.rank) : rows;
  return {
    top: kept.slice(0, 10).map((x, i) => ({ rank: x.rank ?? i + 1, title: x.title || x.keyword || x.name })),
    promoted: rows.length - kept.length,   // goes into the heading: "N promoted rows skipped"
  };
}

Вот 7 рекламных позиций, которые встретились за 14 запусков. Они занимали только два места: 4-е и 8-е. Их заголовки похожи на обычные темы из списка трендов, поэтому выдаёт их только пустой rank. Последний заголовок, «Несколько кремов для век обвинили в недобросовестной рекламе», выглядит как новость, но у него тоже нет rank, поэтому мы пропускаем и его. Чтобы оставлять такие записи, нужно отдельное правило.

Static data — самый лёгкий способ хранить данные между запусками в n8n. В документации n8n указаны два ограничения. Эти данные не сохраняются при ручных тестовых запусках, а только когда опубликованный воркфлоу запускается триггером. Кроме того, при высокой частоте запусков этот механизм может работать ненадёжно. Поэтому при ручном запуске «пересечение с прошлым запуском» всегда пустое.

Так и должно быть. Для данных, которые нельзя терять, документация рекомендует таблицы данных.

Этот узел также считает стоимость двумя способами. «Сумма по ответам» складывает значения billing.charged_usd из всех вызовов. «Фактическое списание» не учитывает вызовы, в которых replayed имеет значение true. Зачем нужны оба числа, показывает тест 3.

1. Преобразуйте данные в файл и запишите на диск. Используйте Convert to File с операцией «Convert to Text File» для поля markdown. Затем запишите файл в папку reports/ узлом Read/Write Files. После каждого запуска должен появляться новый файл report-<time>.md.

Если на этом шаге сообщается, что путь недоступен для записи или запрещён, сначала проверьте N8N_RESTRICT_FILE_ACCESS_TO. Путь должен находиться внутри разрешённой там папки.

1. Опубликуйте воркфлоу и перезапустите n8n. Выполните n8n import:workflow --input=A.json, затем n8n publish:workflow --id=eiDailyReport01, затем n8n start. В журнале запуска должны быть строки «Scheduler started» и «Processed 0 draft workflows, 2 published workflows».

У публикации из командной строки есть деталь, которую легко упустить. publish:workflow пишет напрямую в базу данных. Команда сама выводит «Changes will not take effect if n8n is running». Работающий n8n увидит изменение только после перезапуска. От этой детали зависит ответ в тесте 1.

Тест 1: вовремя ли происходит запуск и с какого момента отсчитываются интервалы «каждые N минут»?

В n8n 2.45 изменился смысл «каждые N минут». На странице документации о персистентном планировщике сказано, что такие расписания «выполняются через равные интервалы, отсчитываемые от публикации воркфлоу». К целым минутам они больше не привязаны. Чтобы сохранить привязку к целым минутам, задайте N8N_SCHEDULER_TRIGGER_NODE_MODE=legacy. Ниже исходный текст, правило выделено бирюзовой рамкой.

Какой же момент считается «публикацией»? Мы опубликовали два воркфлоу из командной строки в 10:32:59 и 10:33:01 SGT. n8n запустился в 10:36:20 и активировал их в 10:36:24. Ответ даёт таблица SQLite scheduled_job. У обеих строк createdAt — 10:36:24.207 и 10:36:24.209, а первый nextRunAt — 10:39:24.206.

Отсчёт начинается, когда работающий n8n активирует воркфлоу, а не когда команда пишет в базу. В редакторе оба события происходят по одному нажатию. С командной строкой между ними прошло 3 минуты 25 секунд.

Дальше все 14 запусков пришлись на одну фазу: 24,206 секунды после каждой 3-минутной отметки, с 10:39:24 до 11:24:24. В обычных запусках выполнение начиналось через 0,008–0,034 секунды после запланированного времени. Это намного меньше нашего порога в 5 секунд. Когда остановок не было, интервал между запусками составлял от 179,978 до 180,013 секунды.

Во время теста мы дважды перезапускали n8n, и фаза не изменилась. После каждого перезапуска строка scheduled_job сохранялась, а значение nextRunAt оставалось привязано к прежней фазе. Перезапуск не начинал отсчёт заново. В этом самое явное отличие от старого планировщика в памяти.

В таблице по порядку приведены все 16 запланированных моментов. Все значения взяты из SQLite и данных запусков, их вычисляет наш скрипт анализа analysis.py. Время указано в SGT.

Последний столбец показывает то, что к планированию не относится. В первом запуске Weibo вернул всего 10 записей, а Douyin — 8. Потом оба почти всегда возвращали по 20 записей — это default_limit обоих в каталоге. Что это значит для стоимости, разобрано в тесте 3.

Что это значит для ежедневного отчёта? Чтобы получать отчёт ровно в 8:00, используйте интервал «Days» и задайте время 8:00. В документации сказано, что почасовые, ежедневные, еженедельные и ежемесячные расписания в повседневном использовании работают одинаково в обоих режимах. Изменение касается только расписаний «каждые N минут» и «каждые N секунд».

Если вы использовали «каждые 30 минут» для запуска в :00 и :30, после обновления до 2.45 запуски будут происходить с интервалом 30 минут, начиная с той секунды, когда вы нажали «опубликовать». Чтобы сохранить запуск в :00 и :30, используйте cron-выражение, например 0 */30 * * * *. По документации, cron от этой настройки не зависит. Можно также задать legacy, но документация помечает legacy как устаревший режим, и в одной из будущих версий его уберут.

Тест 2: что происходит с запуском, пока n8n не работает?

Это самое крупное изменение в 2.45, и на него мы потратили больше всего времени. Старый планировщик в памяти держит следующий запуск внутри процесса. В документации сказано прямо: «Restarts lose pending runs» — при перезапуске ожидающие запуски теряются. Запуск, время которого пришлось на простой, пропускается. Персистентный планировщик сначала записывает каждый запуск в базу, поэтому пропущенный запуск «остаётся в базе». Если n8n вернётся в пределах льготного периода, запуск начнётся с опозданием. Если позже — решает политика пропусков.

Чтобы сравнить две политики при одном и том же простое, мы опубликовали два воркфлоу. Воркфлоу A — это отчёт с политикой по умолчанию «Don't Run Missed Executions». Воркфлоу B — heartbeat. Он не вызывает API и только записывает время в файл, поэтому ничего не стоит. B использует «Run the Most Recent Missed Execution».

Оба запускаются каждые 3 минуты в одной фазе. Скрипт останавливал n8n сигналом SIGTERM по ID процесса, ждал завершения процесса и запускал его снова в заданное время. Скрипт записывал в журнал все временные отметки.

Первая остановка: 32 секунды, в пределах льготного периода. Мы остановили n8n в 10:45:12 SGT, запустили в 10:45:40, к 10:45:44 он был готов. Запланированный момент 10:45:24 пришёлся на середину остановки. Запуск уже был в таблице scheduled_task до остановки. Окно материализации, N8N_SCHEDULER_MATERIALIZATION_WINDOW, по умолчанию 60 секунд, поэтому строка для каждого запуска появляется примерно за минуту. После перезапуска A и B начались в 10:45:46,0 — с задержкой 21,8 секунды, в пределах 60-секундного льготного периода.

Одна деталь: до остановки missedAfter у обеих строк было 10:46:24.206 — запланированное время плюс 60 секунд. После перезапуска n8n изменил его на 10:46:45.677. Похоже, перезапуск дал новый льготный период от момента старта. Мы видели это только один раз и дальше правило не проверяли.

Вторая остановка: 6 минут 44 секунды; за это время наступили два запланированных момента. Мы остановили n8n в 10:49:00 SGT, запустили в 10:55:40, к 10:55:44 он был готов. Оба запланированных момента, 10:51:24 и 10:54:24, пришлись на остановку, и к моменту возобновления работы n8n их 60-секундный льготный период уже истёк. Результат совпал с документацией.

Воркфлоу A не запустился ни в один из этих моментов, а следующий его запуск состоялся в 10:57:24. Воркфлоу B запустился один раз, в 10:55:53. Этот запуск относится к последнему запланированному моменту, 10:54:24, и произошёл с задержкой 89,0 секунды. Отдельного догоняющего запуска для 10:51:24 воркфлоу B не делал.

Одних данных запусков мало: несостоявшегося запуска в них просто нет. Поэтому мы включили в n8n метрики Prometheus и один раз прочитали /metrics в 10:56:30 SGT, после второго перезапуска. Счётчики обнуляются при старте процесса, поэтому показывают только вторую остановку.

Интервалы между запусками отчёта хорошо показывают обе остановки. Первая задержала один запуск на 21,8 секунды, поэтому интервалы до и после него составили 201,8 и 158,2 секунды. В сумме это по-прежнему 360 секунд, так что фаза не сдвинулась. Из-за второй остановки два запуска были пропущены, поэтому интервал составил 540,0 секунды — ровно три периода.

Три источника согласуются: данные запусков, таблица scheduled_task и метрики. Поэтому мы считаем J4 пройденным. Каждый счётчик описан на странице переменных планировщика. У n8n есть и готовый дашборд Grafana. Если ваш отчёт читают другие люди, настройте оповещение на occurrences_misfired_total. Рост счётчика означает, что отчёт за какой-то день не сформировался.

Какая политика подходит для ежедневного отчёта? Мы рекомендуем «Run the Most Recent Missed Execution» вместе с ключом на основе даты из шага 3. Ежедневный отчёт должен формироваться один раз в день. После остановки вам нужен отчёт за сегодня. Если n8n возобновит работу на следующий день, догоняющий запуск использует новую дату и новый ключ, поэтому вы получите отчёт за новый день. Политика пропуска по умолчанию подходит для задач, которые бесполезны с опозданием, например для ежеминутного heartbeat.

Выбирайте льготный период исходя из времени перезапуска. По документации, он должен быть больше интервала исполнителя и не меньше окна материализации, что при настройках по умолчанию даёт 60 секунд. Если перезапуск при обновлении на вашей машине занимает 3 минуты, задайте в узле льготный период 300 секунд.

Тест 3: деньги и повтор, который выглядит оплаченным

Каждый запуск вызывает 4 возможности со списками трендов: twitter/trending для США и для Мексики, weibo/trending и douyin/trending. В каталоге EveryInfra, прочитанном в 10:15 SGT, у всех трёх price_usd равен 0.000556 за вызов. Значит, каждый запуск должен стоить 4 × $0.000556 = $0.002224. Ниже реальный ответ каталога для twitter/trending. Бирюзовыми рамками отмечены цена и смысл collected_at.

Без учёта повторов каждый из 14 запусков стоил ровно $0.002224. Итого — $0.031136.

Одним ответам мы не поверили. После теста мы прочитали журнал вызовов на сервере через GET /portal/api/logs и сверили каждый request_id. Все 56 оплаченных вызовов из 14 запусков были в журнале. У каждого cost — 40 кредитов, то есть $0.000556, что до 6-го знака после запятой совпадает с charged_usd в ответе. У 14 вызовов, вернувших 422, записей в журнале вызовов не было вовсе. Значит, за них ничего не списано.

Ловушка — в повторе. В 10:40:46 SGT мы через curl снова отправили вызов Weibo из запуска 10:39 с тем же ключом daily-report-20261026-1039-weibo-default.

Ответ — 200, с заголовком idempotent-replayed: true и replayed: true в теле. id был от первого вызова — req_a5c69df94c2f4d66. У нового запроса был свой ID в заголовке x-request-id: req_7278432b29f64594. Второго списания в журнале сервера не было. Но в блоке billing по-прежнему стояло "charged": true, "charged_usd": 0.000556.

Причину объясняет текст OpenAPI. Повтор возвращает сохранённый первый ответ с «тем же billing, без повторного выполнения и списания». Значит, billing описывает первое списание, а не этот вызов.

В ежедневном отчёте это выглядит как на диаграмме ниже. Мы задали KEY_BY значение day и дважды запустили воркфлоу вручную командой n8n execute; по записям запусков они начались в 10:56:46.565 и 10:57:04.358 SGT. Во втором запуске все 4 вызова были повторами, и фактическое списание составило $0. Отчёт, который складывает все charged_usd, как делается в большинстве руководств, показал бы для второго запуска $0.002224.

Поэтому учитывайте только вызовы, где replayed не равно true. Наш отчёт показывает оба числа. Если они расходятся, в этот день был повторный запуск, и можно выяснить, кто и зачем его сделал.

Мы проверили и обратный случай. В 10:40:54 SGT мы отправили тот же ключ с другими параметрами. API вернул 409 idempotency_conflict, а в next_steps было сказано: «отправьте новый запрос с новым ключом. Ничего не списано». Значит, ключ на основе даты должен включать ещё платформу и параметры. Иначе два разных списка в один день будут блокировать друг друга. Поэтому ключ в шаге 3 содержит платформу и страну.

Сколько это стоит

Ниже приведён расчёт стоимости всего теста. Все суммы показывают фактические списания после учёта повторов и сверены с журналом сервера.

Стоимость вашего отчёта зависит от расписания:

Все цены взяты из поля price_usd каталога. Данные каталога считаны 26 октября 2026 года в 10:15 SGT. Последняя строка показывает, зачем нужен ключ: сколько бы раз вы ни перезапускали отчёт в течение дня, платите один раз.

Ещё одну деталь легко упустить. Списки трендов оплачиваются за вызов, а не за запись. За те же $0.000556 список X для Мексики вернул 71 запись, а списки Weibo и Douyin вернули по 20 записей (медианы по 14 запускам). В пересчёте на 1 000 записей разница составляет 3.6×.

Число записей тоже меняется от вызова к вызову. В первом запуске в 10:39 SGT Weibo вернул 10 записей, а Douyin — 8. В следующих 13 запусках Douyin всегда возвращал 20 записей, а Weibo — от 15 до 20, чаще всего 20. Это default_limit обоих в каталоге, а max_limit у weibo/trending — 200. В правилах списка трендов Weibo описан список из 50 позиций, который обновляется каждую минуту, так что по умолчанию вы получаете только его часть.

Наш отчёт берёт только топ-10, поэтому в первом запуске потерялись лишь 2 места Douyin. Нужен полный список? Проверьте в каталоге, разрешён ли limit. Затем подтвердите число записей одним реальным вызовом. И записывайте в отчёт число записей каждого запуска.

Не делайте оценок по значению по умолчанию. Короткий ответ тоже стоит $0.000556, поэтому учитывайте его, когда считаете цену за запись.

Тест 4: один ошибочный вызов, а отчёт всё равно приходит

В каждом запуске пятый вызов передаёт для Douyin boards значение hot. Правильное значение — hotspot. Во всех 14 запусках этот вызов вернул 422, отчёт всё равно пришёл, а остальные 4 списка были полными. Вот реальный ответ из запуска в 10:39:

Почему такой ответ удобен для автоматизации? Он содержит данные для исправления ошибки в машиночитаемых полях. allowed перечисляет допустимые значения. did_you_mean предлагает ближайшее из них. retryable: false показывает, что повтор того же запроса снова завершится ошибкой.

Первая строка next_steps — «Ничего не списано». Наш узел отчёта копирует message и did_you_mean в отчёт, и читатель видит, что значение нужно заменить на hotspot. Статус 422 — это «Unprocessable Content» из RFC 9110: запрос составлен правильно, но его содержимое невозможно обработать. Повторная попытка с тем же запросом не может быть успешной.

Эта схема работает благодаря переключателю «Never Error» из шага 4. Без него n8n помечает запуск как неудачный и запускает ваш воркфлоу обработки ошибок (страница об обработке ошибок), и в этот день отчёта нет. Для файла, который люди читают каждый день, один недостающий список гораздо лучше, чем отсутствие файла. В таблице — ответы, которые мы вызвали в тесте или нашли в тексте OpenAPI, и что с ними должен делать отчёт.

Первые пять случаев мы вызвали сами. Ответ 401 получен при вызове без ключа в 10:18 SGT, исходный ответ у нас сохранён. Последние две строки взяты из текста OpenAPI. В этом тесте мы их не вызывали.

Тест 5: та же возможность через узел MCP Client

В n8n есть и узел MCP Client. Он использует инструменты любого MCP-сервера как обычный шаг воркфлоу. MCP-эндпоинт EveryInfra — https://api.everyinfra.com/mcp. Для получения списка инструментов ключ не нужен; в 10:39 SGT их было 25. Мы один раз вызвали everyinfra_call_api с теми же параметрами, что и в одном REST-вызове:

{
  "type": "@n8n/n8n-nodes-langchain.mcpClient",
  "typeVersion": 1.1,
  "parameters": {
    "endpointUrl": "https://api.everyinfra.com/mcp",
    "authentication": "bearerAuth",
    "tool": { "__rl": true, "mode": "id", "value": "everyinfra_call_api" },
    "inputMode": "json",
    "jsonInput": "{\"platform\":\"weibo\",\"action\":\"trending\",\"params\":{}}",
    "options": { "timeout": 90000 }
  },
  "credentials": { "httpBearerAuth": { "id": "eiBearer000001", "name": "EveryInfra API Key" } }
}

Мы запустили его в 10:39:52 SGT командой n8n execute --id=eiMcpCheck0001. Узел работал 9,3 секунды. Значением content[0].text оказался объект с полями верхнего уровня id, platform, action, results, count, billing, quota и async_hint. count — 10, списание — $0.000556, вызов был в журнале сервера (req_0e075488e27f44e6, 10:40:01). У каждого результата были rank, title, hot_value, is_hot, is_new, label, url и platform — те же поля, что в REST-ответе в то же время. Транспорт — Streamable HTTP по умолчанию, один из двух стандартных транспортов в спецификации MCP от 2025-11-25.

Тогда почему не использовать MCP для отчёта? Причин две. Во-первых, узел HTTP Request может отправить заголовок Idempotency-Key, а в аргументах инструмента узла MCP Client для него нет места. Без ключа догоняющий запуск лишён защиты «одно списание в день». Во-вторых, MCP лучше всего подходит, когда модель сама выбирает инструмент и формирует аргументы.

Отчёту с 5 фиксированными вызовами это не нужно. MCP Client уместен после узла AI Agent, где модель читает отчёт и решает, стоит ли подробнее изучить какую-то тему. Для этого в n8n есть отдельный узел MCP Client Tool.

У командной строки есть ещё одна ловушка. Пока работает сервис n8n, n8n execute запускает собственный брокер задач на том же порту. Мы задали N8N_RUNNERS_BROKER_PORT=5692 только для этой команды, и всё заработало. Как настроить подключение к MCP-серверу EveryInfra в Claude, Cursor и других клиентах, читайте в руководстве по настройке удалённого MCP. Подробности — на странице MCP-сервера.

Насколько изменились списки за 45 минут

Хватит ли одного отчёта в день? Это зависит от того, как быстро меняется каждый список. Мы наблюдали за списками всего 45 минут, с 10:39 до 11:24 SGT, поэтому результаты показывают изменения в пределах часа, а не дня. Все числа наш скрипт анализа analysis.py вычисляет по 14 записям о запусках.

По каждому списку цифры такие. В списке горячих тем Weibo мы считаем по rank и исключаем рекламные позиции (от 0 до 2 среди первых 10 позиций в каждом запуске; при подсчёте по позициям они выглядели как новые темы). Между соседними запусками в топ-10 сохранялось от 7 до 10 тем, то есть каждые 3 минуты менялось от 0 до 3 тем, а в 9 из 13 пар менялась не более чем одна тема. Тема на 1-м месте сменилась дважды: в 10:57 и в 11:18 SGT. Только 4 темы входили в топ-10 и первого, и последнего запуска.

Закреплённая тема на 1-м месте в списке трендов Douyin не менялась ни разу. Между соседними запусками сохранялось от 7 до 10 тем, а 5 тем входили и в первый, и в последний список (в первом запуске было всего 8 записей).

Первые 8 запусков оба списка X не менялись совсем. Затем, в запуске в 11:12, оба изменились одновременно. В списке по США «Chiefs» поднялись на 1-е место. В списке по Мексике на 2-е место вошёл новый хештег телешоу, а из предыдущего запуска сохранились только 6 тем. После этого оба списка снова стали стабильными. Между первым и последним запусками в списке по США сохранились 9 тем, в списке по Мексике — 6.

Ниже для сравнения показано, как рекламные позиции влияют на показатели Weibo:

Посмотрим на те же данные с другой стороны. За 45 минут в топ-10 Weibo попала 21 разная тема из рейтинга (27, если считать по позициям; дополнительные 6 дают сменяющиеся рекламные позиции), в топ-10 Douyin — 18 тем, в X для Мексики — 14, а в X для США — 11. Отчёт, который запускается раз в день, показывает по 10 тем из каждого списка. Для X это охватывает большую часть тем за час. Для Weibo больше половины тем, попавших в топ-10 за этот час, то есть 11 из 21, в ваш отчёт так и не попадут.

Эти цифры показывают, что четыре списка меняются с разной скоростью. Они не показывают, что какой-то из списков лучше. Списки X были свежими при каждом вызове: значение collected_at было на несколько секунд раньше момента вызова, например 10:39:34 и 10:42:35 SGT. Большую часть времени топ-10 не менялся, а затем изменился скачком. Всё это время верхние места занимали темы о выборах в Бразилии, прошедших накануне вечером.

Мы увидели только одно такое обновление, поэтому не можем сказать, как часто X обновляет свои списки. На странице о рекомендациях трендов X сказано, что тренды — это темы, которые «популярны сейчас». Там же сказано, что X исключает новые аккаунты и аккаунты с небольшим числом подписчиков и определяет тренды по странам, регионам и городам. Поэтому тренды X меняются медленнее, чем список горячих тем Weibo, который обновляется каждую минуту.

Для вашего отчёта это значит, что для отслеживания главных событий в X хватит одного-двух запусков в день. Чтобы следить за изменениями в Weibo, одного запуска в день мало: он пропускает многие темы, которые успевают подняться и исчезнуть между запусками. Запускайте отчёт чаще или сохраняйте каждый список и включайте в отчёт «все темы, замеченные сегодня».

Попал ли ключ на диск?

Отчёт работает долго. Ключ, попавший в экспорт, данные запусков или резервную копию, тоже остаётся там надолго.

После теста, в 11:25 SGT, мы остановили n8n и поискали текст ключа в трёх местах. Первое место — вся папка данных n8n: база SQLite, её WAL-файл, журнал событий и файл настроек. Второе — 16 отчётов в reports/. Третье — все исходные файлы этой статьи. Совпадений: 0.

В таблице учётных данных хранится только зашифрованное значение. В данных запуска выход узла HTTP Request содержит статус, заголовки и тело ответа, но не заголовки запроса. В данных об ошибках вызовов с кодом 422 ключа тоже не было.

Данные об ошибках мы проверили намеренно. 14 октября n8n исправила похожую проблему: бюллетень GHSA-qmvv-q3c9-wpp7 описывает узлы Git, MongoDB Atlas Vector Store и Google Cloud Storage. Когда операция завершалась ошибкой, эти узлы записывали пароль или токен из своих учётных данных в данные об ошибке. Пользователь, которому видны данные запусков, но не учётные данные, мог прочитать секрет. Исправленные версии: 1.123.85, 2.44.1 и 2.43.5.

Узла HTTP Request в этом списке нет, и наш тест утечки не обнаружил. Но этот случай показывает, почему после каждого обновления стоит искать секреты в данных запусков.

С какими проблемами мы столкнулись на практике

Каждая строка ниже описывает то, что произошло во время этого теста, в хронологическом порядке. Большинство из них — не ошибки n8n, а результат сочетания новых настроек по умолчанию в версии 2.x и работы через командную строку.

Больше всего времени у нас отняла первая строка, и её легко понять неправильно. В ошибке упоминается пакет для логирования, не связанный с n8n, поэтому она выглядит как проблема Node.js. На самом деле установка просто не завершилась, и чистая переустановка всё исправляет.

Третью и четвёртую строки читайте вместе. В редакторе запись в базу и активация воркфлоу происходят одним нажатием, поэтому фаза — это секунда, в которую вы нажали кнопку. При работе через командную строку с перезапуском фазой становится секунда, в которую перезапуск активирует воркфлоу. В нашем тесте эти два момента разделяли 3 минуты 25 секунд. Если вы разворачиваете отчёты из командной строки и интервал «каждые N минут» должен совпадать с другой системой, учитывайте, что фаза задаётся при перезапуске.

Предупреждения об устаревании стоит один раз внимательно прочитать. В нашем журнале запуска в 10:36 SGT их было шесть. N8N_UNVERIFIED_PACKAGES_ENABLED по умолчанию станет false. Режим внутреннего раннера задач будет удалён, поэтому нужно перейти на внешний режим. Тайм-аут задачи N8N_RUNNERS_TASK_TIMEOUT сократится с 300 до 60 секунд.

Два ограничения узла сжатия будут снижены. И ещё одно: «Running n8n outside a container is deprecated». Для отчётов важен тайм-аут задачи. После 3.0 задача узла Code, которая выполняется дольше 60 секунд, будет остановлена, поэтому задайте тайм-аут сами или разделите работу на части. Внешний режим описан на странице о раннерах задач.

Как проверить это самостоятельно в SQLite

Редактор n8n показывает список запусков, но не показывает «запуск, который должен был состояться, но не состоялся». Планировщик с сохранением состояния хранит сведения о таких случаях в двух таблицах, и их можно прочитать через sqlite3. С помощью этих трёх запросов мы проверили пункты J1–J4:

DB=$HOME/Downloads/n8n-lf25/home/.n8n/database.sqlite
# 1. Phase, interval, misfire policy and grace of each schedule
sqlite3 -header $DB "select name, intervalSeconds, nextRunAt, lastFiredAt, misfirePolicy, misfireGraceSeconds from scheduled_job;"
# 2. Each run in the queue: planned time, actual start, latest allowed start
sqlite3 -header $DB "select id, jobId, status, scheduledFor, startedAt, missedAfter from scheduled_task order by id;"
# 3. Runs that executed: trigger mode, status, start time (all times in UTC)
sqlite3 -header $DB "select id, workflowId, mode, status, startedAt from execution_entity order by id;"

Учтите три момента. Во-первых, все значения времени указаны в UTC. Для сингапурского времени прибавьте 8 часов, для нью-йоркского до 1 ноября вычтите 4 часа.

Во-вторых, в scheduled_task хранятся только запуски, попавшие в очередь. По умолчанию окно составляет 60 секунд. Запуск, срок которого наступил во время простоя, а льготный период истёк к моменту возвращения n8n, в этой таблице так и не появится. Поэтому потерянные запуски нельзя посчитать по числу строк. Вычислите их по фазе или посмотрите метрику n8n_scheduler_occurrences_misfired_total.

Так мы и сделали: у запусков A в 10:51:24 и 10:54:24 SGT строк нет. Мы нашли их по формуле «фаза + 180 с × k» и сверили со значением счётчика, равным 2.

В-третьих, завершённые запуски по умолчанию хранятся один день (N8N_SCHEDULER_RETENTION равен 86 400 секундам), а неудачные и пропущенные хранятся семь дней. Для ежемесячного анализа выгружайте их по расписанию. Мы выгрузили три таблицы в executions.json, и наш скрипт анализа analysis.py вычисляет по этому файлу все значения времени в этой статье.

В этой таблице для каждого критерия прохождения указаны данные, по которым он проверялся. Все файлы мы храним.

Справочник полей: все поля, которые может использовать отчёт

Отчёт использует только название и позицию каждой записи, но 4 возможности возвращают больше данных. Мы сверили эту таблицу поле за полем с response_fields из каталога, прочитанного в 10:15 SGT. Столбец «Этот запуск» показывает, какие поля присутствовали в записях запуска в 10:39.

Три особенности удалось обнаружить только при построчной проверке исходных ответов. Во-первых, у закреплённой записи Douyin (is_pinned: true) нет hot_value, а у остальных 19 записей это поле есть. При сортировке по популярности закреплённая запись оказывается последней, поэтому сортируйте записи Douyin по rank.

Во-вторых, одно поле, event_time, приходило в двух форматах. В закреплённой записи было «2026-10-26 10:41:56» без часового пояса. В остальных записях было «2026-10-25T01:23:31.000Z» в UTC. Простое сравнение строк даёт неверный результат, поэтому разбирайте оба формата.

В-третьих, Weibo ни разу за 14 запусков не вернул category. Не рассчитывайте, что поле есть всегда. Читайте его со значением по умолчанию, например x.category ?? '', иначе в тот день, когда поля не окажется, узел Code выбросит ошибку. Другие значения boards могут вести себя иначе, их мы не проверяли.

Все параметры и поля описаны на странице API трендов X, странице трендов Weibo и странице трендов Douyin. Обзоры платформ: API для парсинга X, API для парсинга Weibo и API для парсинга Douyin.

Тот же вызов в коде

Если вы пока не хотите устанавливать n8n, эта команда curl отправляет тот же запрос, что и узел HTTP Request на шаге 4. С её помощью можно сначала проверить API-ключ и параметры в терминале.

curl -s https://api.everyinfra.com/api/v1/social \
  -H "Authorization: Bearer ${EVERYINFRA_API_KEY}" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: daily-report-$(TZ=America/New_York date +%Y%m%d)-twitter-us" \
  -d '{"platform":"twitter","action":"trending","params":{"country":"us"}}' \
  | jq '{replayed, count, top3: [.results[0:3][].name], charged_usd: .billing.charged_usd}'

Запустите её второй раз в тот же день, и replayed станет true. charged_usd по-прежнему показывает первое значение, но нового списания не происходит. Обратите внимание: дата в ключе здесь берётся по нью-йоркскому времени. Выберите для ключа один часовой пояс и используйте его же в n8n. Иначе отчёт около полуночи может получить новый ключ раньше или позже, чем вы ожидаете.

Чтобы получить API-ключ и посмотреть формат запроса и ответа, начните с раздела Быстрый старт. Цены на каждую возможность указаны на странице Тарифы. Ваш отчёт также проверяет возвраты средств за неудачные вызовы? В руководстве по сверке возвратов за неудачные вызовы показано, как сопоставить каждое списание с charge_id и журналом вызовов.

Другие способы решить ту же задачу

Для ежедневного отчёта n8n не обязателен. В этой таблице приведены только факты, которые мы смогли проверить, и указано, когда подходит каждый способ.

«Cron не догоняет» относится к классическому cron. Некоторые таймеры умеют выполнять пропущенные запуски, например таймер systemd с Persistent=true. Мы их не тестировали. Наше правило: для одного-двух вызовов без ветки обработки сбоев проще cron и curl. Если шагов три и больше, сбои должны попадать в отчёт или поток редактируют другие люди, используйте n8n. Для сравнения: в нашем руководстве по мониторингу репутации на нескольких платформах используется другой подход.

Когда такая схема не подходит

Каждый запуск должен выполняться ровно один раз. Политика догоняющего запуска выполняет не более одного пропущенного запуска, причём самого последнего. Она не выполняет все пропущенные запуски. В документации сказано, что ни одна политика не выполняет по одному всю накопившуюся очередь запусков. Если вам нужен результат каждого почасового запуска, например для расчёта среднего за день, проверяйте плановое время в отчёте и заполняйте пропуски сами.

Одна база SQLite используется несколькими инстансами n8n. Мы тестировали только один инстанс. В документации сказано, что при нескольких основных инстансах каждый запуск забирает один из них, но для этого нужны Postgres и режим очереди, которые мы не тестировали.

Вам нужен полный список. По умолчанию каждый вызов возвращает 20 записей, а первый вызов вернул только 10 и 8 (см. тест 3).

Вам нужно длинное окно наблюдения. Период измерений составил 45 минут утром 26 октября по сингапурскому времени (SGT). Это был день после выборов в Бразилии, когда одна новость возглавляла все списки.

Последние изменения

• 20 октября 2026 г.: в n8n 2.45 персистентный планировщик включён по умолчанию. См. историю изменений и примечания к релизу на GitHub. В этом релизе также удалена неиспользуемая переменная N8N_SCHEDULER_MIN_INTERVAL. Что это значит для вас: после обновления у интервала «каждые N минут» появится новая фаза, а простои будут обрабатываться иначе, поэтому проверьте политику обработки пропущенных запусков в каждом воркфлоу по расписанию.
• С версии 3.0: только Docker. Согласно странице о несовместимых изменениях 3.0, поддержка npm и npx n8n прекращается, а старые узлы Cron и Interval удаляются. Что это значит для вас: установка через npm в этой статье подходит для тестов; долго работающие отчёты перенесите в Docker, а узлы Cron замените на Schedule Trigger.
• 14 октября 2026 г.: обновление безопасности n8n. В обновлении перечислены 15 бюллетеней, в том числе об учётных данных, попадающих в сведения об ошибках выполнения. Что это значит для вас: держите self-hosted инстансы на последнем патче и после обновления проверяйте данные запусков на наличие секретов.
• 14 октября 2026 г.: по данным Censys, у n8n больше доступных из интернета инстансов, чем у любого другого продукта, связанного с ИИ. В отчёте Censys насчитано 113 926 хостов. Что это значит для вас: инстанс n8n для отчётов на вашем компьютере незачем делать доступным из интернета.
• 6 октября 2026 г.: Diagrid объявляет об отказоустойчивом выполнении для n8n. В платном пресс-релизе говорится, что после сбоя воркфлоу продолжают работу с узла, на котором произошла ошибка. Реестр идемпотентности предотвращает повторные побочные эффекты. Что это значит для вас: n8n 2.45 гарантирует, что запуск, назначенное время которого уже наступило, не потеряется. Сбой во время выполнения запуска — другая проблема, и партнёры уже работают над ней.
• 12 октября 2026 г.: ZoomInfo выпускает нативный узел для n8n. В релизе Business Wire говорится, что компания также предоставляет свои данные через API и MCP. Что это значит для вас: сервисы данных подключаются к n8n через специальные узлы и через MCP. У EveryInfra пока нет специального узла для n8n; в этой статье используются универсальные узлы HTTP Request и MCP Client.
• 22 октября 2026 г.: черновик IETF об Idempotency-Key достиг версии 08. См. страницу на IETF datatracker. Что это значит для вас: идемпотентность через заголовок запроса становится стандартом, поэтому ключ на основе даты подойдёт и для других API.

FAQ

Как задать часовой пояс для Schedule Trigger в n8n? (Источник: подсказка Google «n8n schedule trigger time zone», дата обращения: 26 октября 2026 г.)

В self-hosted n8n по умолчанию используется America/New_York. Задайте GENERIC_TIMEZONE, например America/Chicago, и перезапустите n8n. Часовой пояс можно также задать в настройках воркфлоу, и он имеет приоритет над настройкой инстанса (страница Schedule Trigger). Мы задали Asia/Singapore в обоих местах, поэтому в именах файлов используется сингапурское время.

Почему Schedule Trigger в n8n не сработал после перезапуска? (Источник: подсказка Google «n8n schedule trigger not running», дата обращения: 26 октября 2026 г.)

Сначала проверьте версию. До версии 2.44 включительно планировщик в памяти, который используется по умолчанию, пропускает каждый запуск, назначенное время которого пришлось на простой. Начиная с версии 2.45 персистентный планировщик выполняет такой запуск с опозданием, если n8n снова запускается в пределах льготного периода (по умолчанию 60 секунд). За его пределами решение зависит от настройки узла «If Execution Is Missed», и по умолчанию запуск также пропускается. Во время нашей остановки длительностью 6 минут 44 секунды политика по умолчанию пропустила два запуска, как и предусмотрено. Чтобы выполнить последний пропущенный запуск вдогонку, выберите «Run the Most Recent Missed Execution» и используйте ключ на основе даты, чтобы за догоняющий запуск не списалась плата повторно.

Как обрабатывать ошибки HTTP Request в n8n, не останавливая воркфлоу? (Источник: подсказка Google «n8n http request error handling», дата обращения: 26 октября 2026 г.)

Включите «Never Error» и «Include Response Headers and Status» в разделе Options узла HTTP Request. Тогда ответ с кодом вне диапазона 2xx передаётся следующему узлу как данные, а ветвление можно настроить по statusCode. В наших 14 запусках ошибочный вызов каждый раз возвращал 422, и отчёт каждый раз приходил. Ошибки EveryInfra содержат next_steps, поэтому их можно вставлять в отчёт как есть.

Что ещё почитать

• Настройка удалённого MCP: как подключить MCP-сервер EveryInfra к Claude, Cursor и другим клиентам.
• Сверка возвратов за неудачные вызовы: как сверить все списания и возвраты средств.
• Как продавать тематические отчёты по комментариям YouTube: ещё один отчёт по расписанию, который запускается раз в месяц.
• Спецификация MCP 2026 и готовность к продакшену: справка о транспортах и аутентификации в MCP.

Источники

1. «Durable scheduler», n8n Docs, октябрь 2026 г., <https://docs.n8n.io/deploy/host-n8n/configure-n8n/durable-scheduler/>
2. «Scheduler environment variables», n8n Docs, октябрь 2026 г., <https://docs.n8n.io/deploy/host-n8n/configure-n8n/basic-configuration/use-environment-variables/scheduler/>
3. «Schedule Trigger node», n8n Docs, октябрь 2026 г., <https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.scheduletrigger/>
4. «Changelog» (персистентный планировщик включён по умолчанию), n8n Docs, 20 октября 2026 г., <https://docs.n8n.io/changelog/>
5. «Release notes» (n8n 2.45 и 2.44), n8n Docs, 20 октября 2026 г., <https://docs.n8n.io/changelog/release-notes/>
6. «Release n8n 2.45.0», n8n на GitHub, 20 октября 2026 г., <https://github.com/n8n-io/n8n/releases/tag/n8n%402.45.0>
7. «v3.0 Breaking changes», n8n Docs, октябрь 2026 г., <https://docs.n8n.io/changelog/v30-breaking-changes/>
8. «Developing v3 features», n8n на GitHub, 2026 г., <https://github.com/n8n-io/n8n/blob/master/.github/DEVELOPING_V3.md>
9. «Install with npm», n8n Docs, октябрь 2026 г., <https://docs.n8n.io/deploy/host-n8n/install-options/install-with-npm/>
10. Метаданные пакета n8n (dist-tags и время релизов), npm registry, дата обращения: 26 октября 2026 г., <https://registry.npmjs.org/n8n>
11. «Use Docker Compose», n8n Docs, октябрь 2026 г., <https://docs.n8n.io/deploy/host-n8n/install-options/install-using-docker-compose/>
12. «One-line setup», n8n Docs, октябрь 2026 г., <https://docs.n8n.io/deploy/host-n8n/install-options/one-line-setup/>
13. «Node.js Releases», Node.js, обновлено 21 октября 2026 г., <https://nodejs.org/en/about/previous-releases>
14. «Set the timezone», n8n Docs, <https://docs.n8n.io/deploy/host-n8n/configure-n8n/basic-configuration/configuration-examples/set-the-timezone/>
15. «Daylight Saving Time Rules», NIST, 2026 г., <https://www.nist.gov/pml/time-and-frequency-division/popular-links/daylight-saving-time-dst>
16. «Time Zone Database», IANA, <https://www.iana.org/time-zones>
17. «Security environment variables», n8n Docs, <https://docs.n8n.io/deploy/host-n8n/configure-n8n/basic-configuration/use-environment-variables/security/>
18. «Read/Write Files from Disk node», n8n Docs, <https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.readwritefile/>
19. «Use the command line», n8n Docs, <https://docs.n8n.io/deploy/host-n8n/configure-n8n/use-the-command-line/>
20. «HTTP Request credentials», n8n Docs, <https://docs.n8n.io/integrations/builtin/credentials/httprequest/>
21. «RFC 6750: Bearer Token Usage», IETF, 2012 г., <https://www.rfc-editor.org/rfc/rfc6750>
22. EveryInfra OpenAPI (ключи идемпотентности, повторы, ошибки), EveryInfra, дата обращения: 26 октября 2026 г., <https://api.everyinfra.com/openapi.json>
23. «The Idempotency-Key HTTP Header Field», draft-08, IETF HTTPAPI WG, 22 октября 2026 г., <https://datatracker.ietf.org/doc/draft-ietf-httpapi-idempotency-key-header/>
24. «HTTP Request node», n8n Docs, <https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.httprequest/>
25. «getWorkflowStaticData», n8n Docs, <https://docs.n8n.io/build/code-in-n8n/cookbook/built-in-methods-and-variables-examples/getworkflowstaticdata/>
26. «Convert to File node», n8n Docs, <https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.converttofile/>
27. «Enable Prometheus metrics», n8n Docs, <https://docs.n8n.io/deploy/host-n8n/configure-n8n/basic-configuration/configuration-examples/enable-prometheus-metrics/>
28. «n8n-scheduler Grafana dashboard», n8n-observability на GitHub, <https://github.com/n8n-io/n8n-observability/tree/main/dashboards/grafana/n8n-scheduler>
29. Каталог возможностей EveryInfra, EveryInfra, дата обращения: 26 октября 2026 г., 10:15 SGT, <https://api.everyinfra.com/api/v1/social/catalog>
30. «Hot search rules», Weibo, <https://m.s.weibo.com/hot/description>
31. «RFC 9110: HTTP Semantics» (422 Unprocessable Content), IETF, 2022 г., <https://www.rfc-editor.org/rfc/rfc9110>
32. «Handle errors gracefully», n8n Docs, <https://docs.n8n.io/build/flow-logic/handle-errors-gracefully/>
33. «MCP Client node», n8n Docs, <https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-langchain.mcpclient/>
34. «MCP Client Tool node», n8n Docs, <https://docs.n8n.io/integrations/builtin/cluster-nodes/sub-nodes/n8n-nodes-langchain.toolmcp>
35. «MCP specification 2025-11-25: Transports», Model Context Protocol, <https://modelcontextprotocol.io/specification/2025-11-25/basic/transports>
36. «Trends Recommendations», X Help Center, <https://help.x.com/en/resources/recommender-systems/trends-recommendations>
37. «Set up task runners», n8n Docs, <https://docs.n8n.io/deploy/host-n8n/configure-n8n/set-up-task-runners/>
38. «GHSA-qmvv-q3c9-wpp7: Credential Secrets Exposed in Execution Error Data», n8n на GitHub, 14 октября 2026 г., <https://github.com/n8n-io/n8n/security/advisories/GHSA-qmvv-q3c9-wpp7>
39. «5 Key Takeaways From Censys' State of the Internet Report», Censys, 14 октября 2026 г., <https://censys.com/blog/state-of-the-internet-report-2026/>
40. «Security update — 01 October 2026», n8n Community, 1 октября 2026 г., <https://community.n8n.io/t/security-update-01-october-2026/318054>
41. «Security update — 14 October 2026», n8n Community, 14 октября 2026 г., <https://community.n8n.io/t/security-update-14-october-2026/321284>
42. «Diagrid Brings Durable Execution to n8n» (платный пресс-релиз), Business Wire через Yahoo Finance, 6 октября 2026 г., <https://finance.yahoo.com/technology/ai/articles/diagrid-brings-durable-execution-n8n-130000140.html>
43. «ZoomInfo Launches Native Integration With n8n Through GTM.AI», Business Wire, 12 октября 2026 г., <https://www.businesswire.com/news/home/20261012317239/en/ZoomInfo-Launches-Native-Integration-With-n8n-Through-GTM.AI>
44. «Faltam 12 dias: consulte propostas das candidaturas que disputam o 2º turno», Высший избирательный суд Бразилии, 13 октября 2026 г., <https://www.tse.jus.br/comunicacao/noticias/2026/Outubro/faltam-12-dias-consulte-propostas-das-candidaturas-que-disputam-o-2o-turno>
45. «An n8n execution can show Success after processing zero items», Reddit r/n8n, <https://www.reddit.com/r/n8n/comments/1xadlkd/an_n8n_execution_can_show_success_after/>