Расписания пайплайнов с логами, ретраями и интеграцией с API
Задайте расписание пайплайну через cron-триггер и запускайте функции как его шаги: проверенные выражения, история выполнения, ретраи и те же секреты и наблюдаемость, что у HTTP-эндпоинтов. Расписание принадлежит пайплайну; это не отдельный сервис.
Обновлено: 2026-06-28
Кратко
Суть ответа
Расписания пайплайнов с логами, ретраями и интеграцией с API. В Inquir пайплайн по расписанию запускает serverless-функции как шаги. HTTP-маршруты могут вызывать те же функции. Они делят секреты воркспейса, историю выполнения, правила оповещений и изоляцию контейнеров. Расписание — тип триггера у пайплайна, а не отдельный продукт.
Когда подходит
- Команды, которым нужны cron-задачи и API-эндпоинты на одной платформе с общей наблюдаемостью
- Задачи, которым нужны ретраи, история и оповещения без отдельного сервиса-планировщика
На что обратить внимание
- Инструменты вроде Heroku Scheduler или EasyCron дают HTTP-вызов по расписанию — но serverless-функцию, модель секретов и слой наблюдаемости всё равно приходится заводить отдельно.
- Когда задача по расписанию вызывает внутренний API, ходит в базу или пишет в объектное хранилище, модель безопасности для этих учёток живёт где-то ещё — обычно в хрупком env-файле.
Нагрузка и где ломается
Что нужно настоящей платформе cron-задач
- Проверка выражения до первого пропущенного запуска
- История выполнения: когда запускалась, сколько шла, что вернула
- Ретраи: автоматический перезапуск при сбое без ручного вмешательства
- Общие секреты с HTTP-маршрутами API (без параллельного env-файла на сервере)
- Оповещения: уведомление, когда задача упала или идёт дольше ожидаемого
Большинство команд начинают с crontab на VPS. Это работает, пока масштаб или размер команды не поставят вопрос «а задача прошлой ночью запускалась?» — и ответ потребует SSH и копания в логах.
Компромиссы
Почему отдельные планировщики не видят всей картины
Инструменты вроде Heroku Scheduler или EasyCron дают HTTP-вызов по расписанию — но serverless-функцию, модель секретов и слой наблюдаемости всё равно приходится заводить отдельно.
Когда задача по расписанию вызывает внутренний API, ходит в базу или пишет в объектное хранилище, модель безопасности для этих учёток живёт где-то ещё — обычно в хрупком env-файле.
Как помогает Inquir
Пайплайны по расписанию рядом с API
В Inquir пайплайн по расписанию запускает serverless-функции как шаги. HTTP-маршруты могут вызывать те же функции. Они делят секреты воркспейса, историю выполнения, правила оповещений и изоляцию контейнеров. Расписание — тип триггера у пайплайна, а не отдельный продукт.
Та же функция, что обслуживает публичный REST-эндпоинт, может быть шагом пайплайна по расписанию. Один деплой, две точки входа, общая наблюдаемость.
Сравнение
Cron-платформы: что получаете и что эксплуатируете
Справочный чеклист для оценки cron-платформ — не маркетинговая таблица возможностей.
| Возможность | crontab | systemd timer | Heroku Scheduler | Inquir |
|---|---|---|---|---|
| Проверка выражения | В момент запуска | При установке юнита | Только фиксированные интервалы | При сохранении |
| История прогонов | Syslog / почтовый спул | journalctl (только на хосте) | Нет | Консоль — хранение 30 дней |
| Ретраи при сбое | Нет | Опция юнита OnFailure= | Нет | Политика на шаг |
| Общие секреты с API | Отдельные файлы .env | Отдельные service-файлы | Отдельные config vars | Те же секреты воркспейса |
| Минимальный интервал | 1 минута | 1 секунда (OnCalendar) | 10 минут | 1 минута |
| Инфраструктура на вас | VPS + демон cron | VPS + systemd | Dyno Heroku | Нет |
Что вы получаете
Возможности расписаний пайплайнов
Проверенные cron-выражения
Выражения проверяются при сохранении. Стандартный cron из 5 полей (минута, час, день, месяц, день недели), минимальный интервал — 1 минута. Ошибки видны сразу, а не на следующем пропущенном запуске.
История выполнения
Каждый cron-запуск создаёт запись выполнения: время старта, контекст триггера, выходы шагов, длительность и статус завершения — всё доступно из консоли.
Ретраи с задержкой
Настройте число попыток и задержку на шаг: экспоненциальный backoff или фиксированная пауза. Упавшие прогоны хранятся в истории выполнения для ручного разбора и replay.
Параллельное выполнение задач
Несколько cron-пайплайнов работают одновременно — без узкого места однопоточного планировщика. При необходимости добавьте защиту от наложения на задачу.
Что дальше
Как задать расписание пайплайна в Inquir
Реализовать обработчик задачи
Напишите serverless-функцию. Держите логику идемпотентной: при редких рестартах планировщика cron-задача может сработать дважды.
Добавить расписание пайплайна
В визуальном редакторе пайплайнов соедините узел cronTrigger с узлом-функцией и введите cron-выражение. Сохраните пайплайн, чтобы проверить расписание.
Задать правило оповещения
Добавьте SLO-оповещение по длительности: уведомлять, когда задача идёт дольше 10 минут или завершается с ошибкой.
Пример кода
Проверка срока сертификатов (cron-задача)
Запускается ежедневно в 08:00 UTC, проверяет срок действия TLS-сертификатов для списка доменов и шлёт оповещение, если какой-то истекает в ближайшие 30 дней.
import tls from 'node:tls'; import net from 'node:net'; async function checkExpiry(hostname) { return new Promise((resolve, reject) => { const socket = tls.connect({ host: hostname, port: 443 }, () => { const cert = socket.getPeerCertificate(); socket.destroy(); resolve(new Date(cert.valid_to)); }); socket.on('error', reject); }); } export async function handler(event) { const domains = process.env.DOMAINS_TO_MONITOR?.split(',') ?? []; const results = await Promise.all( domains.map(async (d) => ({ domain: d, expiry: await checkExpiry(d) })), ); const expiringSoon = results.filter( (r) => r.expiry.getTime() - Date.now() < 30 * 86_400_000, ); if (expiringSoon.length > 0) await sendAlert(expiringSoon); return { checked: domains.length, expiringSoon: expiringSoon.length }; }
Когда подходит
Когда использовать пайплайны по расписанию
Когда это уместно
- Команды, которым нужны cron-задачи и API-эндпоинты на одной платформе с общей наблюдаемостью
- Задачи, которым нужны ретраи, история и оповещения без отдельного сервиса-планировщика
Когда лучше выбрать другое
- Простые разовые задачи, где crontab на VPS работает и ни разу не привёл к пропущенному запуску, который стоило бы расследовать
Частые вопросы
Частые вопросы
Можно ли проверить функцию до следующего запуска по расписанию?
Да — вызовите функцию напрямую через шлюз или консоль. Это проверяет обработчик функции, а не расписание пайплайна или весь процесс.
Как быть с наложением задач?
Добавьте в обработчик распределённую блокировку или проверку «пропустить, если уже идёт». Для идемпотентных задач наложение безопасно по построению — используйте паттерн с курсором.