UpWatch
Регистрация
Мониторинг cron-задач

Как контролировать cron-задачи через ping и узнавать о пропущенном запуске

Практическое руководство по выбору таймаута, отправке сигнала только после успешной работы, защите URL с токеном и диагностике ситуаций, когда фоновая задача перестала выполняться.

Создать аккаунтОткрыть материалы
Настройка мониторинга cron-задачи через ping URL в UpWatch

Краткий ответ

После создания cron-монитора UpWatch выдаёт уникальный адрес вида /ping/{token}. Фоновая задача должна обращаться к этому адресу после успешного завершения.

Каждый полученный ping сохраняется как успешный запуск. Если новый сигнал не приходит за установленный таймаут, UpWatch создаёт неуспешный запуск и открывает инцидент.

Новый ping после пропуска интервала считается восстановлением. UpWatch не запускает cron-задачу сам и не знает, успешно ли она обработала данные, если сигнал отправляется независимо от результата.

Почему фоновые задачи ломаются незаметно
Работающий сайт и успешный healthcheck приложения не подтверждают выполнение процессов, запускаемых отдельно по расписанию.

Планировщик не запустил команду

Cron-служба остановлена, расписание удалено, изменён пользователь или допущена ошибка в конфигурации.

Процесс завершился с ошибкой

Скрипт запустился, но упал из-за базы данных, внешнего API, недостатка памяти или ошибки кода.

Задача зависла

Процесс существует, но не завершает работу и не доходит до отправки успешного ping.

Контейнер или сервер был выключен

Задача физически не могла запуститься, однако публичная часть сервиса продолжает работать на другом узле.

Изменился путь к команде

После релиза, обновления окружения или переноса проекта cron вызывает несуществующий файл.

Ошибка обнаруживается по последствиям

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

Как работает cron-монитор
В основе находится обратная проверка: не UpWatch вызывает задачу, а задача сообщает UpWatch о своём успешном выполнении.
Этап 1

Создание монитора

Пользователь создаёт cron-монитор, задаёт название и допустимый таймаут.

  • Для монитора создаётся уникальный токен.
  • На основе токена формируется ping URL.
  • Таймаут определяет максимально допустимый период без сигнала.
  • Количество cron-мониторов зависит от тарифа.
Этап 2

Запуск фоновой задачи

Cron, systemd timer, планировщик контейнера или другой механизм запускает реальную команду.

  • UpWatch не запускает эту команду.
  • Расписание остаётся в вашей инфраструктуре.
  • Задача может выполняться на любом сервере с доступом в интернет.
  • Важно контролировать код завершения основной команды.
Этап 3

Отправка ping после успеха

После успешной работы задача обращается к уникальному URL.

  • Endpoint отвечает кодом 200.
  • Тело ответа содержит текст ok.
  • Время последнего сигнала обновляется.
  • В истории появляется успешный запуск.
Этап 4

Обнаружение пропуска

Worker регулярно ищет мониторы, у которых последний ping старше допустимого таймаута.

  • Если ping не приходил ни разу, это также считается проблемой после таймаута.
  • Создаётся неуспешный запуск с понятным описанием.
  • Последующие проходы не создают бесконечные одинаковые ошибки.
  • Сбой может открыть инцидент и запустить уведомления.
Этап 5

Восстановление

Когда задача снова отправляет ping, появляется успешный запуск.

  • Система видит успешный сигнал после начала инцидента.
  • Инцидент закрывается как восстановленный.
  • Можно отправить уведомление о восстановлении.
  • История сохраняет период отсутствия сигналов.
Примеры отправки ping
Во всех примерах сигнал должен отправляться только после успешного завершения основной команды.

Простой запрос через curl

curl --fail --silent --show-error \
  "https://upwatch.ru/ping/ВАШ_ТОКЕН"

Параметр --fail заставляет curl завершиться ошибкой при неуспешном HTTP-ответе.

Linux cron: ping только после успеха

0 * * * * /path/to/job.sh && \
  curl --fail --silent --show-error \
  "https://upwatch.ru/ping/ВАШ_ТОКЕН"

Оператор && не выполнит curl, если основная команда завершилась с ненулевым кодом.

Shell-скрипт

#!/usr/bin/env bash
set -euo pipefail

/path/to/job.sh

curl --fail --silent --show-error \
  "https://upwatch.ru/ping/ВАШ_ТОКЕН"

При ошибке job.sh скрипт остановится до отправки успешного сигнала.

Запрос из PHP

<?php

runCriticalJob();

$response = file_get_contents(
    'https://upwatch.ru/ping/ВАШ_ТОКЕН'
);

if ($response !== 'ok') {
    throw new RuntimeException(
        'UpWatch не подтвердил ping'
    );
}

Ping вызывается после основной операции. В боевом коде нужно также настроить сетевой таймаут.

Запрос из Python

import requests

run_critical_job()

response = requests.get(
    "https://upwatch.ru/ping/ВАШ_ТОКЕН",
    timeout=10,
)
response.raise_for_status()

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

Запрос из Go

runCriticalJob()

client := &http.Client{
    Timeout: 10 * time.Second,
}

response, err := client.Get(
    "https://upwatch.ru/ping/ВАШ_ТОКЕН",
)
if err != nil {
    return err
}
defer response.Body.Close()

if response.StatusCode != http.StatusOK {
    return fmt.Errorf(
        "ping вернул статус %d",
        response.StatusCode,
    )
}

У HTTP-клиента обязательно должен быть ограниченный таймаут.

Как выбрать таймаут
Таймаут должен учитывать расписание, нормальную длительность задачи и разумный запас на задержки.
Расписание задачиПример таймаутаПочему не ровно интервалРиск слишком большого значения
Каждые 5 минут7–10 минутНужен запас на длительность и задержку запуска.Сбой будет обнаружен слишком поздно.
Каждые 15 минут20–25 минутОдин небольшой сдвиг не должен сразу создавать ложный инцидент.Можно пропустить несколько ожидаемых запусков.
Каждый час70–90 минутУчитывается время выполнения и задержка планировщика.Проблема останется незаметной больше часа.
Один раз в сутки25–27 часовЗапуск может немного сместиться относительно точного времени.Пропущенный ежедневный процесс обнаружится только на следующий день.
Один раз в неделю7 дней и несколько часовНужен ограниченный запас, но не ещё одна полная неделя.Ошибка может оставаться незаметной слишком долго.
После каждого события без расписанияCron-монитор обычно не подходитНельзя определить ожидаемый максимальный интервал между сигналами.Нерегулярность будет создавать ложные инциденты.
Как правильно настроить cron-мониторинг
Качество мониторинга зависит не только от UpWatch, но и от того, в каком месте задача отправляет сигнал.
Шаг 1

Выберите критичную задачу

Не каждую техническую команду нужно превращать в отдельный монитор.

  • Резервное копирование.
  • Синхронизация данных.
  • Импорт или экспорт.
  • Рассылка уведомлений.
  • Генерация отчётов.
  • Очистка или агрегация данных.
Шаг 2

Определите нормальное расписание

Запишите, как часто задача должна успешно завершаться.

  • Учитывайте реальный интервал, а не только строку cron.
  • Учтите длительность обработки.
  • Учтите допустимые задержки инфраструктуры.
  • Не используйте cron-монитор для полностью нерегулярного события.
Шаг 3

Создайте cron-монитор

Укажите понятное название и рассчитанный таймаут.

  • Название должно описывать реальную задачу.
  • Не называйте все мониторы просто «Cron».
  • Сохраните созданный ping URL.
  • Не публикуйте URL в открытом репозитории.
Шаг 4

Добавьте ping после основной операции

Это самый важный этап всей настройки.

  • Не отправляйте ping в начале задачи.
  • Не отправляйте ping безусловно в finally.
  • Отправляйте сигнал только после подтверждённого успеха.
  • Используйте ненулевой код завершения при ошибке.
Шаг 5

Настройте сетевой таймаут

Запрос к UpWatch не должен зависнуть и заблокировать рабочий процесс.

  • Используйте ограниченный таймаут HTTP-клиента.
  • Обрабатывайте неуспешный HTTP-статус.
  • Решите, должен ли сбой самого ping влиять на код завершения задачи.
  • Не делайте бесконечные повторные запросы.
Шаг 6

Проведите контролируемый тест

Проверьте успешный сигнал и искусственно пропущенный интервал.

  • Выполните задачу вручную.
  • Убедитесь, что появился успешный запуск.
  • На тестовом мониторе временно прекратите ping.
  • Проверьте открытие инцидента.
  • Верните ping и проверьте восстановление.
Почему cron-монитор открыл инцидент
Пропущенный ping показывает отсутствие подтверждения, но точную причину нужно искать в вашей инфраструктуре.
СимптомВозможная причинаЧто делать
Пинг ещё ни разу не приходилURL не добавлен в задачу, код не был развёрнут, задача не запускалась или используется неправильный токен.Выполните ping вручную и проверьте конфигурацию реальной команды.
Пинг перестал приходить после релизаИзменился путь к скрипту, окружение, контейнер, пользователь или расписание.Проверьте последний релиз, cron-конфигурацию и журналы запуска.
Задача выполнилась, но монитор открыл инцидентPing-запрос завершился ошибкой, не был выполнен или ушёл по старому URL.Проверьте вывод curl, HTTP-статус, токен и сетевой доступ к UpWatch.
Инциденты возникают регулярно без реального сбояТаймаут установлен слишком близко к интервалу или длительность задачи нестабильна.Измерьте реальные интервалы между успешными завершениями и увеличьте разумный запас.
Монитор всегда успешен, хотя задача падаетPing отправляется до работы, безусловно либо ошибка основной команды игнорируется.Переместите ping после успешной операции и проверьте код завершения.
После восстановления инцидент не закрываетсяНовый успешный ping не был получен или монитор выключен.Выполните запрос вручную, проверьте ответ ok и состояние монитора.
Ping возвращает 404Токен неправильный, устарел или был перегенерирован.Скопируйте актуальный URL из настроек монитора и обновите задачу.
Ping возвращает 200, но задача фактически ничего не сделалаСкрипт отправляет сигнал без проверки бизнес-результата.Добавьте проверку результата операции перед ping.
Как избежать ложной уверенности
Сам факт HTTP-запроса к ping URL ещё не доказывает правильность фонового процесса.

Отправляйте ping в самом конце

Сигнал должен означать, что вся критичная часть задачи действительно завершилась.

Проверяйте бизнес-результат

Команда могла завершиться с кодом 0, но обработать ноль записей из-за логической ошибки.

Не раскрывайте токен

Любой человек с URL может создать ложный успешный ping.

Используйте отдельный монитор на задачу

Один общий ping для нескольких процессов не покажет, какой именно процесс перестал работать.

Не ставьте слишком большой таймаут

Большой запас уменьшает ложные срабатывания, но делает обнаружение настоящей проблемы медленным.

Сохраняйте собственные журналы

UpWatch показывает отсутствие сигнала, а внутренние логи нужны для поиска первопричины.

Что доступно в UpWatch
Cron-монитор использует ту же модель истории, инцидентов и уведомлений, что и остальные типы мониторинга.

Уникальный ping URL

Для каждого cron-монитора создаётся отдельный адрес с токеном.

Настраиваемый таймаут

Пользователь задаёт максимально допустимый период без сигнала.

История сигналов

Каждый успешный ping сохраняется как отдельный успешный запуск.

Ошибка при пропуске

После превышения таймаута создаётся неуспешный запуск с количеством секунд без ping.

Инцидент и восстановление

Пропуск сигнала может открыть инцидент, а новый ping закрывает его.

Уведомления

Для начала и восстановления применяются общие каналы уведомлений.

Ограничения

  • UpWatch не запускает cron-задачу и не управляет её расписанием.
  • Ping подтверждает только факт обращения по URL.
  • Если ping отправляется до завершения работы, монитор создаёт ложную уверенность.
  • Человек, получивший URL с токеном, может отправить ложный сигнал.
  • Cron-монитор не читает внутренние логи задачи.
  • Монитор не знает количество обработанных записей и бизнес-результат без отдельной проверки.
  • Нерегулярные задачи без максимального ожидаемого интервала плохо подходят для этой модели.
  • Точность обнаружения зависит от установленного таймаута и периодичности worker.
Частые вопросы

UpWatch сам запускает cron-задачу?

Нет. Задача запускается вашей системой, а после успеха сообщает UpWatch о выполнении.

Когда нужно отправлять ping?

После успешного завершения всей критичной операции.

Что вернёт ping URL?

При корректном токене endpoint возвращает HTTP 200 и текст ok.

Что произойдёт, если ping не придёт вовремя?

После превышения таймаута появится неуспешный запуск, который может открыть инцидент.

Что закроет инцидент?

Новый успешный ping после начала проблемы.

Можно ли использовать один URL для нескольких задач?

Технически несколько процессов могут обратиться к одному URL, но тогда невозможно понять, какой из них перестал работать. Лучше использовать отдельный монитор.

Безопасно ли хранить ping URL в репозитории?

Нет. URL содержит токен, позволяющий создавать успешные сигналы. Его лучше хранить как секрет окружения.

Как подобрать таймаут для ежедневной задачи?

Возьмите один день, прибавьте обычную длительность задачи и ограниченный запас на задержку запуска.

Связанные материалы
Дополнительные руководства помогут связать настройку с API, историей запусков, инцидентами и уведомлениями.
История проверок

Где смотреть успешные ping, пропущенные интервалы и время восстановления.

Инциденты

Как пропуск сигнала превращается в период проблемы и закрывается новым ping.

Уведомления

Как подключить события начала и восстановления по email, Telegram и MAX.

Мониторинг после релиза

Какие страницы, API и фоновые процессы проверять после выкладки.

Поставьте критичные задачи на контроль
Создайте отдельный cron-монитор для каждого важного процесса и отправляйте ping только после успешной работы.
Создать аккаунтОткрыть справочный центр
UpWatch
Мониторинг сайтов, API и фоновых задач.
info@upwatch.ru
© 2026 UpWatch. Все права защищены.