Документация

Надёжность пингов

Мониторинг обязан быть надёжнее того, что он мониторит. Практически это значит одно: пинг никогда не должен ни задерживать вашу задачу, ни ронять её.

Таймауты обязательны

У curl по умолчанию нет общего лимита времени. Зависший сокет — не редкость (потерянные пакеты, чёрная дыра на файрволе, DNS без ответа), и без таймаута cron-задача будет висеть, пока её не убьют.

curl -fsS -m 10 --connect-timeout 5 --retry 3 -o /dev/null https://ping.cronalive.com/<uuid>

Флаг	Что делает
`-m 10`	жёсткий предел на весь запрос, включая ретраи
`--connect-timeout 5`	отдельный предел на установку соединения
`--retry 3`	повтор при сетевой ошибке и 5xx, пауза удваивается
`--retry-connrefused`	считать «connection refused» поводом для повтора (по умолчанию — нет)
`-f`	ненулевой код выхода на 4xx/5xx — иначе curl «успешен» на любой ответ
`-s -S`	без прогресс-бара, но с текстом ошибки: cron иначе шлёт письмо на каждый запуск

Ориентир: пинг — это несколько сотен байт. Десяти секунд на весь запрос хватает с запасом, а 30 и больше уже сравнимы с интервалом частых задач.

Не фоните пинг без таймаута

Соблазн понятен: дописать & и не ждать сеть вовсе. Так делать не стоит:

фоновый curl без -m живёт неограниченно долго. Задача раз в минуту — и через сутки на сервере тысячи зависших процессов;
cron считает задачу завершённой, когда завершились все её процессы: фоновый пинг может держать запись в списке задач;
код выхода фонового процесса теряется — вы не узнаете, что пинги вообще не доходят.

Если фоновый запуск всё-таки нужен (например, пинг из интерактивного скрипта), таймаут обязателен:

# так — можно
curl -fsS -m 10 -o /dev/null "$PING" &

# так — нет: процесс может не завершиться никогда
curl "$PING" &

Пинг не должен ронять задачу

Недоступность мониторинга — не повод останавливать бэкап. Глушите ошибку явно, особенно если скрипт запущен с set -e:

signal() { curl -fsS -m 10 --retry 3 -o /dev/null "$PING$1" || true; }

В сниппетах для Python, Node и PHP то же самое сделано через перехват исключения. Наши SDK ведут себя так же по умолчанию: сигнал либо уходит быстро, либо молча теряется.

Что будет, если сигнал не дошёл

Ничего страшного — и это осознанное поведение, а не снисхождение. Потерянный пинг не нужно навёрстывать:

следующий прогон задачи пришлёт новый пинг и вернёт чек в up;
если задача при этом действительно не отработала, чек уйдёт в down — то есть ложного «всё хорошо» не будет;
единственный риск — ложный алерт из-за сетевой аварии у вас. От него и защищает --retry вместе с разумным grace.

Ретраить сигнал в цикле внутри задачи не нужно: это удвоит задержку и не добавит информации.

Несколько ping-доменов

Приём пингов живёт на нескольких доменах и деплоится независимо от дашборда. Актуальный список отдаёт открытый эндпоинт:

curl -s https://app.cronalive.com/api/v1/ping-domains

В сниппетах на странице чека запасной домен уже подставлен через || — вторая попытка уходит только если первая не удалась:

curl -fsS -m 10 https://ping.cronalive.com/<uuid> || curl -fsS -m 10 https://ping2.cronalive.com/<uuid>

SDK читают этот список сами. Список может пополняться — хардкодить его в своих скриптах не стоит.

Лимиты частоты

Пинги ограничены, но так, чтобы никогда не ломать heartbeat-клиент:

≤ 5 пингов в секунду на чек — всё сверх лимита отбрасывается;
≤ 100 запросов в секунду с одного IP — то же самое;
суточные квоты пингов — по тарифу.

Ключевая деталь: отброшенный пинг получает в ответ 200 OK, а не 429. Так задумано. Клиент с -f не должен считать это ошибкой и не должен уходить в ретраи — иначе лимит породил бы шторм повторов ровно в тот момент, когда система и так под нагрузкой. Такой пинг просто не записывается, статус чека он не меняет.

Практический вывод: если задача пингует чаще пяти раз в секунду, это почти наверняка цикл в скрипте, а не бизнес- требование. Мониторьте прогон целиком, а не каждую итерацию.

Смотрите также

Сниппеты — готовый код со всеми флагами;
Сигналы /start, /fail и длительность;
Статусы и жизненный цикл — grace, flap damping;
API Reference — в том числе GET /api/v1/ping-domains.