Пайплайны по расписанию с историей, ретраями и логами
Добавьте cron-триггер в пайплайн для повторяющейся работы: выражения проверяются при сохранении, история выполнения видна рядом с HTTP-вызовами, ретраи настраиваются, а секреты и логи общие с API-функциями — без отдельного сервиса расписаний или crontab на VPS.
Обновлено: 2026-06-28
Кратко
Суть ответа
Пайплайны по расписанию с историей, ретраями и логами. Каждая задача по расписанию — пайплайн с cron-триггером. Платформа проверяет cron-выражение при сохранении, хранит время следующего запуска на пайплайн и создаёт запись вызова на каждое выполнение — всё доступно без SSH. Выбор лидера через advisory-lock в Postgres гарантирует, что каждое расписание срабатывает на одном узле, даже если воркеров несколько.
Когда подходит
- Ночной ETL, ежечасная синхронизация, недельные отчёты, ротация сертификатов
- Любая повторяющаяся задача, которой нужны видимая история прогонов и ретраи
На что обратить внимание
- Когда состояние задач живёт на одном хосте, каждый деплой может сбросить расписание, каждая SSH-сессия — потенциальный выстрел в ногу, а каждая замена VPS — перечитывание двухлетнего runbook.
- Секреты в файлах
.envна сервере — кошмар для аудита; записи crontab не версионируются вместе с кодом приложения.
Нагрузка и где ломается
Тихие сбои традиционных задач по расписанию
- Crontab на VPS: вывод уходит в почту root, которую никто не читает; ретраев при сбое нет
- systemd timers: надёжнее, но логи разбросаны, секреты вручную, истории нет
- Kubernetes CronJob: правильные примитивы, но накладные расходы кластера для небольших команд
Задачи по расписанию падают тихо чаще любого другого примитива бэкенда. Задача крутится на VPS, скрипт выходит с ненулевым кодом, ошибка уходит в почтовый спул — и никто не знает, пока данные не устареют на три дня.
Компромиссы
Почему crontab на сервере не переживает рост команды
Когда состояние задач живёт на одном хосте, каждый деплой может сбросить расписание, каждая SSH-сессия — потенциальный выстрел в ногу, а каждая замена VPS — перечитывание двухлетнего runbook.
Секреты в файлах .env на сервере — кошмар для аудита; записи crontab не версионируются вместе с кодом приложения.
Как помогает Inquir
Пайплайны по расписанию как полноценный serverless
Каждая задача по расписанию — пайплайн с cron-триггером. Платформа проверяет cron-выражение при сохранении, хранит время следующего запуска на пайплайн и создаёт запись вызова на каждое выполнение — всё доступно без SSH. Выбор лидера через advisory-lock в Postgres гарантирует, что каждое расписание срабатывает на одном узле, даже если воркеров несколько.
Планировщик опрашивает каждые 30 секунд (минимальный интервал — 1 минута), поэтому срабатывание укладывается в ~30 с от запланированного времени. Задачи по расписанию делят секреты воркспейса и тот же стек наблюдаемости, что HTTP-маршруты: ночной ETL, недельные отчёты и ежечасная синхронизация видны в истории выполнения рядом с вызовами вебхуков и API.
Что вы получаете
Возможности расписаний пайплайнов
Проверка cron-выражений
Выражения проверяются при сохранении пайплайна — некорректная запись падает сразу, а не тихо на следующем тике.
История прогонов и логи
Каждое выполнение по расписанию создаёт запись вызова: время старта, длительность, статус завершения, выходы шагов. Доступно без SSH.
Ретраи и защита от наложения
Настройте число попыток и задержку на шаг. Добавьте ключи идемпотентности для защиты от наложения, когда долгая задача выходит за свой интервал.
Общие секреты
Задачи по расписанию используют те же секреты воркспейса, что HTTP-маршруты, — без параллельных файлов .env на сервере.
Что дальше
Как задать расписание пайплайна в Inquir
Написать обработчик задачи
Обычная serverless-функция. Секреты — из переменных окружения; на каждый шаг возвращайте структурированный выход.
Добавить расписание пайплайна
В визуальном редакторе пайплайнов соедините узел cronTrigger с узлом-функцией и введите cron-выражение. Сохраните пайплайн, чтобы проверить расписание.
Следить за историей прогонов
Откройте историю выполнения: каждый запуск, длительность и выход — без доступа по SSH.
Пример кода
Ночная синхронизация с курсором
Обработчик по расписанию читает курсор из окружения, забирает инкрементальные обновления, идемпотентно делает upsert и возвращает новый курсор для следующего запуска.
export async function handler(event) { // event.trigger?.type === 'schedule' when fired by a cronTrigger node const since = process.env.SYNC_CURSOR ?? new Date(Date.now() - 86_400_000).toISOString(); const records = await source.fetchUpdatedSince(since); if (records.length === 0) return { synced: 0, cursor: since }; await destination.upsertBatch(records); // idempotent by record ID const newCursor = records.at(-1)?.updatedAt ?? since; // Store cursor for next run (update env var or external store) return { synced: records.length, cursor: newCursor }; }
Когда подходит
Пайплайны по расписанию подходят для…
Когда это уместно
- Ночной ETL, ежечасная синхронизация, недельные отчёты, ротация сертификатов
- Любая повторяющаяся задача, которой нужны видимая история прогонов и ретраи
Когда лучше выбрать другое
- Расписания чаще раза в минуту — минимальный интервал cron 1 минута; планировщик срабатывает в пределах ~30 с от запланированного времени, но точность до секунды не гарантирует
Частые вопросы
Частые вопросы
Может ли одна функция обслуживать HTTP и пайплайн по расписанию?
Да. Укажите тот же ID функции в узле-функции пайплайна и в HTTP-маршруте шлюза. Cron-триггер запускает пайплайн, который вызывает этот шаг.
В каком часовом поясе интерпретируются cron-выражения?
Для продакшен-расписаний используйте UTC, если требования не привязаны жёстко к рабочим часам по местному времени. Зафиксируйте допущение о часовом поясе в названии пайплайна.
Каков минимальный интервал cron?
Одна минута. Планировщик опрашивает каждые 30 секунд, поэтому реальное срабатывание может отстать от запланированной минуты до 30 секунд. Не рассчитывайте на интервалы короче 1 минуты и на точность до секунды.