Dlaczego Twoje zadania cron zawodzą po cichu (i jak to wykryć)

Zadania cron domyślnie zawodzą bez ostrzeżenia. Dowiedz się, jak monitorowanie heartbeat wykrywa awarie natychmiast, zanim staną się sytuacją krytyczną.

Opublikowano 25 czerwca 2026 — Ostatnia aktualizacja 30 czerwca 2026 — Phil Wilson

Problem z cronem

Cron jest niezawodny pod jednym względem: wykona Twoje polecenie zgodnie z harmonogramem. Jest zawodny pod innym, ważniejszym względem: nie informuje Cię, gdy Twoje polecenie zawiedzie.

Twój serwer działa. Demon cron pracuje. Harmonogram uruchamia się punktualnie. Ale skrypt, który wskazałeś, kończy działanie z niezerowym statusem, przekracza limit czasu lub brakuje mu pamięci. Nikt o tym nie wie. Zadaniem crona jest uruchomienie procesu, a nie sprawdzenie, czy się powiódł.

To nie jest błąd crona. Tak został zaprojektowany cron. Cron powstał przed erą internetu. Został zbudowany w czasach, gdy zadania zapisywały do plików dziennika, a człowiek sprawdzał je okresowo. Ten model nie skaluje się do nowoczesnej infrastruktury, gdzie jeden deweloper zarządza dziesiątkami zaplanowanych zadań na wielu serwerach.

Ile kosztują Cię ciche awarie crona

Cicha awaria kopii zapasowej oznacza, że odkrywasz ją, gdy potrzebujesz kopii. Być może trzy tygodnie później, po incydencie uszkodzenia bazy danych. Różnica między momentem, gdy kopia przestała działać, a momentem, gdy jej potrzebowałeś, to dane, których nie możesz odzyskać.

Cicha awaria kolejki e-mail oznacza, że klienci przestają otrzymywać powiadomienia. Resetowanie haseł, potwierdzenia zamówień, potwierdzenia płatności. Na początku nikt nie narzeka, bo nikt nie wie, czego brakuje. Kiedy to zauważysz, masz tysiące niedostarczonych e-maili i zdezorientowanych użytkowników.

Cicha awaria eksportu danych oznacza, że Twoje analizy są błędne. Twoje dashboardy pokazują trendy oparte na nieaktualnych danych. Podejmujesz decyzje na podstawie niekompletnych informacji. Błąd narasta, im dłużej pozostaje niewykryty.

Dlaczego monitorowanie uptime tego nie wykrywa

Twój monitor uptime mówi, że serwer działa. Twoje API zwraca 200. Twój dashboard się ładuje. Wszystko jest w porządku według Twojego panelu monitorowania.

Ale żadne z tych sprawdzeń nie mówi Ci, czy kopia zapasowa z ostatniej nocy została ukończona. Nie wiedzą, czy Twoje rozliczenie zostało uruchomione. Nie wiedzą, czy potok danych, który zasila Twoje analizy, został zakończony.

Monitorowanie uptime odpowiada na pytanie: „Czy mogę osiągnąć ten punkt końcowy?”. Monitorowanie heartbeat odpowiada na pytanie: „Czy to zadanie zostało wykonane?”. To pytania uzupełniające się. Potrzebujesz obu.

Jak działa monitorowanie heartbeat

Monitorowanie heartbeat jest proste. Każde zaplanowane zadanie otrzymuje unikalny adres URL z tajnym tokenem. Na końcu zadania dodaj jedną linię, która wysyła ping na ten adres URL:

curl -s https://pingwatchdog.com/api/v1/heartbeat/hw_YOURTOKEN

Jeśli ping dotrze w oczekiwanym oknie czasowym, kontrola heartbeat zostaje zaliczona. Jeśli okno zamknie się bez pingu, monitor wyzwala alert.

Konfigurujesz oczekiwany interwał. Jeśli kopia zapasowa działa co 6 godzin, ustaw interwał na 6 godzin. Dodaj okres karencji, jeśli czas trwania zadania jest zmienny. 10-minutowy okres karencji oznacza, że monitor nie alarmuje, chyba że ping spóźnia się o 10 minut.

To cała konfiguracja. Jeden adres URL. Jedno polecenie curl. Zero plików konfiguracyjnych.

Konfiguracja w praktyce

Oto wpis cron dla nocnej kopii zapasowej bazy danych:

0 2 * * * /usr/local/bin/backup-db.sh && curl -s https://pingwatchdog.com/api/v1/heartbeat/hw_YOURTOKEN

&& ma znaczenie. Oznacza: „Uruchom curl tylko jeśli skrypt kopii zapasowej zakończy się statusem 0 (sukces)”. Jeśli kopia zapasowa zawiedzie, curl nigdy się nie uruchomi. Żaden ping nie dotrze. Otrzymasz alert.

Jeśli chcesz monitorować, czy skrypt w ogóle się uruchomił (nawet jeśli zawiódł), użyj ; zamiast && i dodaj obsługę błędów wewnątrz skryptu, aby zgłosić status. Ale w większości przypadków && jest tym, czego potrzebujesz. Zależy Ci na sukcesie, nie tylko na wykonaniu.

Co monitorować za pomocą heartbeatów

Zacznij od zadań, których cicha awaria najbardziej by zabolała:

Kopie zapasowe baz danych: To najczęstszy przypadek użycia i ten o najwyższym koszcie awarii. Kopia zapasowa, o której nie wiesz, że jej brakuje, jest gorsza niż jej całkowity brak.

Kolejki dostarczania e-maili: Jeśli Twoje e-maile transakcyjne lub marketingowe przestają być wysyłane, chcesz wiedzieć w ciągu minut, nie godzin.

Fakturowanie i generowanie faktur: Nieudane fakturowanie oznacza utratę przychodów. Heartbeat na zadaniu fakturowania wykrywa to przed końcem miesiąca.

Synchronizacje i eksporty danych: Jeśli Twój potok analityczny lub synchronizacja hurtowni danych zawiedzie, Twoje raporty są błędne. Heartbeat informuje Cię w oczekiwanym interwale.

Odnowienie certyfikatów: Jeśli używasz certbota lub podobnych narzędzi z automatycznym odnawianiem, dodaj heartbeat. Wygaśnięcie certyfikatu to jedna z najbardziej możliwych do uniknięcia przyczyn przestojów.

Rotacja i czyszczenie logów: Jeśli rotacja logów zawiedzie, Twój dysk się zapełni. Twój serwer przestanie działać. Heartbeat wykrywa awarię rotacji, zanim dysk będzie pełny.

Monitorowanie heartbeat a usługi monitorowania cron

Narzędzia takie jak Healthchecks.io i Cronitor koncentrują się wyłącznie na monitorowaniu crona i zaplanowanych zadań. Robią to dobrze. Niektóre dodają funkcje, takie jak śledzenie czasu trwania zadań i trendy wydajności.

PingWatchdog obejmuje monitorowanie heartbeat wraz z monitorowaniem uptime i monitorowaniem SSL na jednej platformie. Nie potrzebujesz osobnego narzędzia do zadań cron. Monitorujesz swoje strony internetowe, API, certyfikaty SSL i zaplanowane zadania z jednego dashboardu z jednym systemem alertów.

To ważne, ponieważ ten sam zespół, który monitoruje uptime, zazwyczaj zajmuje się zadaniami cron. Konsolidacja narzędzi oznacza mniej dashboardów do sprawdzania, mniej kanałów alertów do konfiguracji i mniej subskrypcji do zarządzania.

Porównaj PingWatchdog z Healthchecks.io, aby zobaczyć, jak nasze monitorowanie heartbeat wypada na tle monitorowania uptime i stron statusu.

Monitorowanie crona w kontenerach i Kubernetes

Jeśli uruchamiasz zadania cron wewnątrz kontenerów Docker lub CronJobs Kubernetes, ten sam wzorzec heartbeat działa. Dodaj polecenie curl na końcu punktu wejścia kontenera lub polecenia CronJob.

Dla Kubernetes:

apiVersion: batch/v1
kind: CronJob
metadata:
  name: db-backup
spec:
  schedule: "0 2 * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: backup
            image: your-backup-image
            command:
            - /bin/sh
            - -c
            - "/backup.sh && curl -s https://pingwatchdog.com/api/v1/heartbeat/hw_YOURTOKEN"
          restartPolicy: OnFailure

Ta sama zasada dotyczy zaplanowanych zdarzeń AWS Lambda, Google Cloud Scheduler, timerów systemd lub każdego innego harmonogramu. Jeśli Twoje zadanie może wykonać żądanie HTTP, może wysłać heartbeat.

Zacznij teraz

PingWatchdog obejmuje monitorowanie heartbeat w każdym planie. Darmowy plan daje 3 monitory heartbeat. Płatne plany oferują do 25.

Dowiedz się więcej o funkcjach monitorowania heartbeat lub skonfiguruj swój pierwszy monitor.