Skip to content
cronitorex.com
Cronitorex Cronitorex

Po co Cronitorex

Problem

Twój cron padł. Nie wiesz o tym. Klient pisze rano: “dlaczego raport nie przyszedł?”.

To powtarzające się dla każdego dev/ops zajmującego się produkcyjnymi systemami. Cron tiket w crontab -e, działa miesiącami, potem cicho przestaje. Powody:

  • exit code != 0, ale stderr leci tylko do /dev/null
  • network glitch wywalił curl zanim doszedł do zewnętrznego API
  • baza padła w nocy, restart procesu zabił long-running ETL
  • ktoś commitnął zmianę w configu i schedule się zmienił z 0 * * * * na 0 0 * * 0
  • expired SSL cert na endpoincie używanym przez script
  • jakikolwiek timeout, OOM, segfault

Każda taka awaria to godziny zanim ktoś zauważy. Czasem dni, jeśli efekt nie jest widoczny dla użytkownika końcowego.

Standardowe rozwiązania i ich pułapki

“Zrobię własny monitoring.” A potem przez weekend będziesz pisał reguły alertów. Do tego utrzymywał stos metryk. Do tego wdrażał agenta na każdym serwerze. Do tego tłumaczył nowemu devowi kolejny język zapytań. Monitoring staje się drugim produktem, który musisz utrzymywać.

“Wystarczy mi tail -f i jak coś, to zobaczę w logach.” Nie zobaczysz. Logi padają w noc i czytasz je rano gdy klient już dzwoni.

“Już jest serwis który to robi” Owszem, kilka. Ale: drogie przy dużej liczbie monitorów, brak self-serve dla zespołów PL/EU, pricing zmienia się co rok. Nasze API jest proste, więc przejście na nie później jest łatwe, jeśli kiedyś zechcesz.

“Uptime Robot do uptime, healthchecks.io do cronów.” Czyli dwa narzędzia, dwa logowania, dwa pricingi. Plus żaden nie daje SSL alertów i nie ma porządnego dashboardu z timeline’em eventów.

Co robi Cronitorex

Jeden produkt do trzech klas monitoringu:

  1. Cron jobs / heartbeats. Wysyłaj ping run na start, complete lub fail na koniec. Alert leci gdy job nie wystartował na czas, leciał za długo, lub się wywalił z exit code != 0.

  2. HTTP uptime checks. Pingaj endpointy z naszej strony. Konfiguracja interval, status code expectations, retry, threshold. Standard.

  3. SSL certificate alerts. Sprawdzamy expiry dat raz dziennie. Ostrzegamy 30/14/7/1 dni przed.

Wszystko w jednym dashboardzie z timeline’em eventów, exportem CSV i prostym REST API.

Dla kogo to jest

  • Solo dev / founder prowadzący produkcyjny system bez zespołu ops.
  • Dev team z kilkudziesięcioma cronami na 3 do 12 serwerach, gdzie nikt nie ma czasu zbudować pełnego observability stacka.
  • Agencja prowadząca cron jobs dla klientów, multi-tenant przez tagi i osobne notyfikacje.
  • SRE / compliance potrzebujący 365-dniowej historii eventów i audit traila.

Co dalej