Monitoring zadań cron

Twój cron padł o 3:00. Dowiedz się o 3:01.

Cron nie raportuje awarii. Zadanie się wywala, harmonogram leci dalej, a Ty dowiadujesz się po kilku dniach od klienta. Cronitorex oczekuje pingu z każdego uruchomienia i alarmuje w ciągu 60 sekund, gdy ping nie dociera.

db-backup ostatnie 30 uruchomień · jedna cicha awaria wykryta

Trzy stany opisują całe uruchomienie

Każde uruchomienie zgłasza run na starcie, a potem complete lub fail na końcu. Wystarczą dwa dodatkowe wywołania w crontabie. Bez agenta, bez demona, bez biblioteki do instalowania.

Z tych pingów Cronitorex buduje timeline per zadanie: czasy trwania, kody wyjścia, historię awarii. Uruchomienie, które startuje i nigdy się nie kończy, też liczy się jako awaria.

/etc/crontab
*/5 * * * * root cronitorex ping db-backup run; /opt/backup.sh && cronitorex ping db-backup complete || cronitorex ping db-backup fail

Cisza to też awaria

Serwer, który padł, nie wyśle pingu fail. Cronitorex zna oczekiwany interwał każdego zadania i czeka dodatkowy okres karencji, który amortyzuje normalne odchyłki. Gdy to okno zamyka się bez pingu, dostajesz alert o pominiętym uruchomieniu.

Obie wartości ustawiasz per monitor. Nocny backup z 15-minutową karencją zachowuje się inaczej niż synchronizacja co 5 minut z karencją 60 sekund.

invoice-sync co 5 minut, zgodnie z harmonogramem
nightly-backup jedno spóźnione, jedno pominięte, jeden alert

Jeden wrapper zamiast trzech pingów

Klient cronitorex.sh opakowuje Twoje polecenie: wysyła run, uruchamia zadanie, mierzy czas trwania, przechwytuje kod wyjścia i ostatnie linie stderr, a na końcu wysyła complete lub fail. Zmieniasz jedno słowo w crontabie, nie swój skrypt.

Masz już pełny crontab? Polecenie discover czyta go i tworzy monitor dla każdego znalezionego zadania, z harmonogramem wziętym wprost z wyrażenia cron.

bash
# opakuj dowolne zadanie: kod wyjścia, czas trwania i stderr przechwycone
cronitorex.sh run db-backup -- /opt/backup.sh

# zaimportuj istniejący crontab jako monitory
cronitorex.sh discover /etc/crontab

Częste pytania o monitoring cronów

Czy działa z innymi schedulerami niż cron?

Tak. Ping może wysłać wszystko, co potrafi wykonać żądanie HTTP: timery systemd, CronJoby Kubernetes, taski Airflow, GitHub Actions, Harmonogram zadań Windows. Cronitorex widzi tylko pingi, nie stojący za nimi scheduler.

Co liczy się jako zdarzenie?

Każdy ping to jedno zdarzenie: run, complete, fail lub skip. Zadanie wysyłające run i complete co godzinę generuje około 1440 zdarzeń miesięcznie, więc 50 000 zdarzeń w planie Free wystarcza na dziesiątki zadań.

Co się dzieje po wyczerpaniu limitu zdarzeń?

API zaczyna zwracać HTTP 402 i nowe pingi nie są przyjmowane do resetu miesiąca albo do zmiany planu. Nic nie jest usuwane; dashboard i historia pozostają dostępne przez cały czas.

Zacznij monitorować w 60 sekund

Zarejestruj się, skopiuj klucz API i wklej polecenie curl do swojego crontaba. To wszystko, co jest potrzebne.