Cron może nie działać od miesięcy i nikt tego nie zauważy. Cała idea Cronitorex bierze się z tej luki między "powinno działać" a "wiemy, że przestało".
Każdy zespół backendowy, z którym rozmawialiśmy, miał tę samą historię, tylko z innymi nazwami. Nocne zadanie, które po cichu przestało działać trzy tygodnie temu. Certyfikat, który wygasł w długi weekend. Worker kolejki, który wywalił się przy starcie i nikt go nie zrestartował, bo nic nie dało znać, że w ogóle padł.
Żadna z tych awarii nie jest egzotyczna. To najnudniejszy możliwy rodzaj: proces, który kiedyś działał, a potem przestał. Problem w tym, że “przestał działać” nie zostawia po sobie stack trace’a, wpisu w logach ani odpowiedzi 500. Zostawia ciszę, a cisza wygląda dokładnie jak sukces, dopóki ktoś nie zacznie szukać wyniku, który nigdy nie nadszedł.
Większość narzędzi do monitoringu jest zbudowana pod obserwowanie rzeczy, które działają i odpowiadają na żądanie. Odpytujesz URL, dostajesz odpowiedź, porównujesz z oczekiwaniem. Ten model sprawdza się przy serwerze WWW, a fatalnie przy cronie, bo cron nie ma żadnego URL-a do odpytania, kiedy akurat nie działa. Nie zapytasz z zewnątrz “czy backup o 2 w nocy się wykonał”. Możesz się tego dowiedzieć wyłącznie od samego zadania, w momencie startu i w momencie zakończenia.
To cała idea monitoringu opartego na pingach: zadanie zgłasza run przy starcie, a complete albo fail na końcu. Jeśli żaden z nich nie dotrze w oczekiwanym oknie czasowym, Cronitorex traktuje tę ciszę jako alert. Bez odpytywania, bez zgadywania, bez odtwarzania wyrażenia cron z zewnątrz.
Wracał do nas też drugi, powiązany problem: certyfikaty. Endpoint HTTPS przechodzi każdy health check aż do poranka, w którym certyfikat wygasa, i wtedy każdy klient widzi zepsutą kłódkę, a nikt wcześniej nie dostał żadnego ostrzeżenia. Check uptime odpowiada na pytanie “czy odpowiada”, nie na pytanie “czy nadal będzie zaufany za tydzień”, więc wbudowaliśmy monitoring wygasania certyfikatów w ten sam produkt zamiast robić z tego osobne narzędzie do doinstalowania.
Chcieliśmy, żeby koszt wdrożenia był bliski zeru. Bez agenta do instalacji, bez demona do łatania, bez SDK do importu. Jeśli Twoje zadanie potrafi uruchomić polecenie powłoki, potrafi wysłać ping przez curl, i to jest cała integracja:
curl "https://api.cronitorex.com/ping/nightly-backup?status=run"
pg_dump mojabaza > backup.sql && \
curl "https://api.cronitorex.com/ping/nightly-backup?status=complete" || \
curl "https://api.cronitorex.com/ping/nightly-backup?status=fail"Chcieliśmy, żeby alert mówił coś konkretnego już w pierwszej linii: który monitor, co się stało, jaki kod wyjścia albo szczegół odpowiedzi podpowiada, od czego zacząć szukanie, zamiast ogólnego “coś jest nie tak”, które każe przeszukiwać pięć różnych usług.
I chcieliśmy, żeby całość była na tyle tania, żeby jednoosobowy zespół z kilkoma cronami mógł korzystać z darmowego planu na zawsze, nie tylko w okresie próbnym. Trzydzieści monitorów, sprawdzanie co 60 sekund, bez karty kredytowej. Płatne plany są dla zespołów, które potrzebują więcej historii, więcej monitorów i kanałów takich jak Slack czy PagerDuty, nie po to, żeby chować podstawową niezawodność za paywallem.
Cronitorex pilnuje dziś trzech rodzajów awarii: pominiętych lub nieudanych zadań cron, endpointów HTTP, które przestają odpowiadać tak jak powinny, oraz certyfikatów zbliżających się do wygaśnięcia. Alerty idą przez email, Telegram, Discord, Slack albo webhook do dowolnego narzędzia, którego już używasz do dyżurów. Każde konto może opublikować publiczną stronę statusu, bo “czy to tylko u mnie” to pytanie, na które Twoi użytkownicy zasługują na uczciwą odpowiedź.
Jeśli kiedykolwiek dowiedziałeś się o awarii od klienta zamiast od własnych narzędzi, to jest dokładnie ta luka, którą chcieliśmy domknąć.
Zarejestruj się, skopiuj klucz API i wklej polecenie curl do swojego crontaba. To wszystko, co jest potrzebne.