Что такое Cron и для чего он нужен
Как устроены Cron и crontab в Unix-подобных системах, из каких полей состоит расписание, какие задачи обычно автоматизируют и почему запуск вручную не гарантирует работу по расписанию.

Cron — классический механизм Unix-подобных систем для запуска команд по расписанию. Пользователь задаёт время и команду в таблице crontab, а cron daemon запускает её в нужные моменты без ручного участия.
Cron используют для резервных копий, очистки временных файлов, периодических импортов, синхронизаций, формирования отчётов и других повторяющихся задач. Его сильная сторона — простота. Слабая — сам факт наличия строки в crontab ещё не доказывает, что задача действительно выполнилась успешно.
Что такое crontab
crontab — таблица расписаний. У отдельного пользователя может быть собственная таблица. Команда crontab позволяет её устанавливать, редактировать и просматривать.
Основные команды:
crontab -l
показывает текущие задания пользователя.
crontab -e
открывает таблицу для редактирования.
Системные задания также могут находиться в /etc/crontab и каталогах вроде /etc/cron.d/; конкретная организация зависит от дистрибутива и реализации cron.
Как выглядит Cron-выражение
Классическая запись содержит пять временных полей и команду:
минута час день_месяца месяц день_недели команда
Например:
0 3 * * * /usr/local/bin/backup.sh
Это означает запуск команды каждый день в 03:00 по времени, которое использует cron на данной системе.
Ещё пример:
*/5 * * * * /usr/local/bin/check.sh
Задача запускается каждые пять минут.
Что означают пять полей
| Поле | Типичный диапазон |
|---|---|
| Минута | 0–59 |
| Час | 0–23 |
| День месяца | 1–31 |
| Месяц | 1–12 |
| День недели | зависит от реализации; часто 0–7 с воскресеньем на границе |
Синтаксис может иметь расширения конкретной реализации. Если переносите сложное расписание между системами, проверяйте manual именно установленного cron.

Примеры задач Cron
Резервная копия ночью
30 2 * * * /usr/local/bin/backup.sh
Очистка временных файлов раз в сутки
0 4 * * * /usr/local/bin/cleanup.sh
Синхронизация каждые 15 минут
*/15 * * * * /usr/local/bin/sync.sh
В production предпочтительнее использовать абсолютные пути и явно понимать окружение процесса.
Почему команда работает вручную, но не работает в Cron
Это одна из самых распространённых проблем.

Другое окружение
Интерактивная shell может иметь богатый PATH, переменные из .bashrc, активированное виртуальное окружение и credentials. Cron запускает команду в более ограниченном окружении.
Вместо:
0 * * * * python script.py
часто надёжнее использовать абсолютные пути:
0 * * * * /usr/bin/python3 /opt/app/script.py
Другой рабочий каталог
Cron не обязан запускать команду из каталога проекта. Относительные пути вроде ./config.json могут перестать находиться.
Либо используйте абсолютные пути, либо явно переходите в каталог:
0 * * * * cd /opt/app && /usr/bin/python3 script.py
Нет нужных переменных окружения
Если скрипт ожидает DATABASE_URL, API key или другой параметр, убедитесь, что он действительно доступен процессу cron безопасным способом.
Права пользователя отличаются
Задание выполняется от конкретного пользователя. Файл, доступный root, может быть недоступен обычному пользователю.
Куда попадает вывод Cron
Поведение зависит от реализации и конфигурации. Классический cron может отправлять stdout/stderr через настроенную почту, а системные журналы могут содержать сведения о запуске daemon.
Для простой задачи вывод часто направляют в отдельный лог:
0 * * * * /usr/local/bin/job.sh >> /var/log/my-job.log 2>&1
Но у такого файла нужно контролировать ротацию, иначе он может расти бесконечно.
В системах с journald часть событий может быть доступна через journalctl; точное имя unit зависит от дистрибутива (cron, crond и т. п.).
Как проверить, что Cron вообще запущен
В systemd-системе сначала найдите фактический unit. В разных дистрибутивах встречаются cron.service и crond.service.
Например:
systemctl status cron
или:
systemctl status crond
Не копируйте имя unit вслепую — проверьте, какой пакет и сервис установлены в вашей системе.
Почему лог запуска ещё не доказывает успех задачи
Cron может честно запустить команду в 03:00, но скрипт завершится через секунду с ошибкой подключения к БД. Для планировщика задача была запущена, а для бизнеса резервная копия не создана.
Поэтому полезно различать:
Cron запустил процесс
≠
процесс успешно выполнил полезную работу
Именно здесь нужны exit code, собственные application logs и контроль результата.

Cron и systemd timers
В Linux с systemd для периодических задач также существуют systemd timers. Они дают другие возможности управления и журналирования. Это не означает, что Cron «не работает» в systemd-системах: cron может быть установлен и запущен как обычный сервис.
Выбор зависит от окружения, требований и принятого стандарта эксплуатации.
Что такое heartbeat для Cron-задачи
Heartbeat monitoring меняет модель проверки.
Вместо того чтобы внешний сервис пытался угадать, отработал ли скрипт, сама задача после успешного выполнения отправляет контрольный HTTP-запрос:
Cron запускает job → job выполняет работу → job отправляет heartbeat
Если ожидаемый heartbeat не пришёл вовремя, это сигнал, что задача не стартовала, зависла или не дошла до контрольной точки.
Важно отправлять heartbeat в правильном месте. Если ping выполняется в первой строке скрипта, он подтверждает только старт, а не успешное завершение.
Какие задачи особенно полезно контролировать heartbeat
- резервные копии;
- регулярные импорты;
- синхронизации данных;
- ETL;
- формирование отчётов;
- отправку периодических пакетов;
- обслуживание очередей;
- cleanup-задачи, если их пропуск критичен.
UpWatch поддерживает Cron/heartbeat-мониторы: для такого сценария задача обращается к выделенному heartbeat URL, а система отслеживает своевременность сигнала. Это дополняет, а не заменяет собственные логи процесса.
Практический чек-лист Cron-задачи
Перед тем как считать задание готовым:
- Выполните команду вручную от того же пользователя.
- Используйте абсолютные пути.
- Проверьте рабочий каталог.
- Проверьте необходимые переменные окружения.
- Сохраните stdout/stderr или application log.
- Проверьте exit code.
- Убедитесь, что расписание соответствует нужному часовому поясу.
- Добавьте контроль результата, если пропуск задачи критичен.
- Для heartbeat отправляйте сигнал после успешной работы, а не только при старте.
Источники
Поведение crontab и формат таблицы описаны в Linux manual pages crontab(1) и crontab(5): таблица содержит инструкции вида «выполнить эту команду в это время», а пользователь управляет своей таблицей через утилиту crontab.
Частые вопросы
Что такое Cron простыми словами?
Cron — планировщик Unix-подобных систем, который запускает заданные команды автоматически в указанное время или с заданной периодичностью.
Что такое crontab?
Это таблица расписаний Cron. В ней указываются временные поля и команды, которые должен запускать cron daemon.
Почему команда работает вручную, но не из Cron?
Частые причины — другой PATH и окружение, другой рабочий каталог, отсутствующие переменные, права пользователя или использование относительных путей.
Доказывает ли лог Cron, что задача успешно завершилась?
Нет. Лог запуска подтверждает только запуск процесса. Сам скрипт может завершиться с ошибкой, поэтому нужно контролировать exit code, результат и собственные логи.
Зачем Cron-задаче heartbeat?
Heartbeat подтверждает, что задача дошла до ожидаемой контрольной точки. Если сигнал не приходит вовремя, можно обнаружить пропущенный или зависший запуск.