Skip to content
cronitorex.com
Cronitorex Cronitorex
ENPL

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 z Prometheusem.” — i będziesz pisał alert rules przez weekend. Plus utrzymywał Grafana stack. Plus deployment node_exporterów. Plus tłumaczył nowemu devowi czemu PromQL ma własną składnię.

“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 kompatybilne — jeśli chcesz migrować, zobacz migration guide.

“Uptime Robot do uptime, healthchecks.io do cronów.” — 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-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.

Dla kogo NIE

  • Aplikacja real-time z metrykami latency p50/p95/p99 co sekundę. To Prometheus/Datadog/New Relic. Nie udajemy że jesteśmy time-series DB.
  • Distributed tracing. To Jaeger / Tempo / Lightstep.
  • Logi aplikacyjne. To Loki / ELK / Better Stack Logs.

Cronitorex robi jedno: pilnuje że coś wystartowało i skończyło się jak należy. To wszystko. Reszty nie próbuje.

Co dalej