Выражения Cron Практическое руководство с реальными примерами

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

Пять полей

Стандартный cron использует пять позиционных полей:

* * * * *
│ │ │ │ └─ Day of week   (0–7, Sunday = 0 or 7)
│ │ │ └─── Month         (1–12)
│ │ └───── Day of month  (1–31)
│ └─────── Hour          (0–23)
└───────── Minute        (0–59)

AWS EventBridge и планировщик Quartz для Java добавляют поле в начало, делая их шесть полей в общей сложности. Все остальные поля сдвигаются вправо. Это вызывает трудности у разработчиков, переключающихся между средами — выражение Quartz, вставленное в стандартный crontab, будет запускаться по неверному расписанию без каких-либо предупреждений. секунды Следуйте пятиполюсной POSIX cron, если ваша платформа не требует шести полей.

Специальные символы

Любое значение — соответствует каждой единице

Символ	Значение	Пример
*	— каждую минуту	* * * * * — в 9 утра и в 5 часов
,	Список ценностей	0 9,17 * * * — каждый час с 9 утра до 5 часов
-	Диапазон	0 9-17 * * * Шаговый интервал
/	— каждые 15 минут	*/15 * * * * Нет конкретного значения (только Quartz/AWS)
?	— 15-е число каждого месяца, любой день недели	0 0 15 * ? Последнее (только Quartz/AWS)
L	— последний день каждого месяца	0 0 L * ? Ближайший день недели (только Quartz/AWS)
W	— ближайший день недели к 15-му	0 0 15W * ? Стандартный

принимает только crontab Если вы видите *, ,, -и /в выражении, оно было написано для Quartz или AWS EventBridge — не копируйте его в Linux crontab без изменений. ?, L, или W Таблица с расписаниями, которые действительно используют разработчики

Это часть, которую стоит сохранить. Создайте и проверьте любое из этих выражений с помощью

Генератора выражений IO Tools Cron Редко подходит для использования в производственной среде.

Описание	Выражение Cron	Примечания
Каждую минуту	* * * * *	Проверка состояния здоровья, короткие циклы запроса
Каждые 5 минут	*/5 * * * *	Оттепление кэша, синхронизация потоков
Каждые 15 минут	*/15 * * * *	Каждые 30 минут
Эквивалентно	*/30 * * * *	Каждый час (в точности в час) 0,30 * * * *
Запускается в :00 каждого часа	0 * * * *	Каждые 6 часов
Синхронизация данных, инкрементальные экспорты	0 */6 * * *	Ежедневно в полночь UTC
Стандартный ежедневный запуск	0 0 * * *	Ежедневно в 9 утра UTC
Генерация утреннего отчёта	0 9 * * *	Дни недели в 9 утра UTC
Работа в рабочие часы (понедельник–пятница)	0 9 * * 1-5	Дни недели в 8:30 утра UTC
Доставка отчёта до начала рабочего дня	30 8 * * 1-5	Каждую воскресенье в 2 часа ночи
Еженедельное техническое обслуживание, резервные копии в периоды низкой нагрузки	0 2 * * 0	Первый день каждого месяца
Расчёты ежемесячных платежей, повторяющиеся отчёты	0 0 1 * *	1 января в полночь
Ежегодные сбросы, задачи начала года	0 0 1 1 *	Проблема с часовым поясом

Cron не имеет осознания часового пояса. Он работает в том часовом поясе, который настроен на сервере — на большинстве систем Linux это UTC. Это обычно не вызывает проблем, пока у вас нет задач, связанных с рабочими часами, или пользователи из разных регионов, которые не понимают, почему «отчёт в 9 утра» приходит в 14:00.

Наиболее безопасные настройки:

Установите сервер в UTC. Преобразуйте в локальное время в логике приложения, а не в расписании cron.

• Комментируйте каждую задачу cron с эффективным локальным временем, чтобы следующий человек, читающий crontab, не должен был угадывать.
• При использовании облачных планировщиков (AWS EventBridge, Google Cloud Scheduler) проверяйте поле часового пояса — большинство поддерживает названия IANA, что устраняет неопределённость.
• Проверка: Рассчитывайте следующие запуски до развертывания

# Always comment with the effective local time
# Runs daily at midnight UTC (= 8pm EST / 5pm PST)
0 0 * * * /usr/bin/python3 /opt/scripts/daily_report.py

Развертывание задачи cron и обнаружение того, что она запускается каждую минуту вместо каждые часы — это ритуал. Пропустите это.

Расчёт следующего запуска IO Tools Cron

The показывает точно, когда ваше выражение запустится в следующий раз — вставьте своё выражение и получите следующие десять временных интервалов до того, как коснуться сервера. Для проверки в командной строке:

Добавление задачи cron на Linux

# Install croniter (Python) for quick expression testing
pip install croniter

python3 -c "
from croniter import croniter
from datetime import datetime

cron = croniter('*/15 * * * *', datetime.utcnow())
for _ in range(5):
    print(cron.get_next(datetime))
"

В конце строки резервного копирования перенаправляет stderr в stdout, так что оба потока попадают в лог-файл. Без этого cron ошибки попадают в почтовый ящик — и никто не проверяет это.

# Open the crontab editor for the current user
crontab -e

# Format: minute hour day month weekday command
# Run backup script daily at 2:30am UTC
30 2 * * * /home/user/scripts/backup.sh >> /var/log/backup.log 2>&1

# Run a Python script every 5 minutes
*/5 * * * * /usr/bin/python3 /home/user/scripts/sync.py

# View current crontab entries
crontab -l

# Edit another user's crontab (requires root)
crontab -u www-data -e

The 2>&1 Запланированный поток GitHub Actions

GitHub Actions использует тот же пятиполе синтаксис cron, всегда в UTC. Нет переключения часового пояса.

Одна оговорка: запланированные потоки GitHub Actions могут быть задержаны до 15 минут в периоды высокой нагрузки. Не полагайтесь на них для задач, требующих точного времени.

name: Nightly Data Export

on:
  schedule:
    # Runs at 1:00 AM UTC every weekday
    - cron: "0 1 * * 1-5"
  workflow_dispatch: # Allow manual trigger

jobs:
  export:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run export script
        run: python scripts/export.py

Когда стандартный cron недостаточен

Стандартный cron решает большинство случаев на одном сервере. Его ограничения становятся проблемами при масштабировании:

Нет повторного запуска при сбое.

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

Лучшее альтернативное решение	Логика повтора и очереди задач
Celery Beat (Python), Sidekiq-Cron (Ruby)	Облачные расписания с повторами
AWS EventBridge + Lambda, Google Cloud Scheduler	Запуск в CI/CD-процессе
Запланированные задачи GitHub Actions	Наблюдаемое управление задачами
Airflow, Prefect, Temporal	Для скриптов на одном сервере, cron по-прежнему является правильным инструментом — он прост, надёжен и не требует зависимостей. Для любых задач, требующих гарантий повтора, распределённого выполнения или видимости сбоев, специализированный очередной механизм быстро окупается.

для построения вашего следующего расписания без необходимости запоминания синтаксиса, и

Используйте Генератор выражений Cron Расчёт следующего запуска Cron для проверки того, что запускается вовремя. Выражения Cron: Практическое руководство с реальными примерами 2

Вам также может понравиться