Monitorování cron úloh: jak poznat, že plánovaná úloha potichu selhala

Stručně: cron vaši úlohu spustí a nikomu neřekne, jak dopadla. Když úloha selže, zasekne se nebo se vůbec nespustí, dozvíte se to až od zákazníka, z prázdné složky se zálohami nebo z chybějící faktury. Monitorování cron úloh to obrací: úloha po dokončení zavolá URL, a pokud volání nepřijde včas, dostanete upozornění. Říká se tomu heartbeat monitoring a v crontabu vám zabere jeden řádek.

Fakta ověřena 14. října 2026 podle manuálové stránky crontab, dokumentace plánovače v Laravelu a dokumentace GitHubu k plánovaným workflow. Zdroje jsou uvedeny na konci článku.

Proč cron úlohy selhávají potichu

Webovou stránku, která přestane fungovat, si někdo všimne během pár minut. Noční úlohy, která přestane fungovat, si všimne až ten, kdo potřebuje její výsledek. Nejčastější příčiny:

1. Jiné prostředí. Podle manuálu crontab nastavuje cron pro vaši úlohu jen SHELL=/bin/sh, LOGNAME a HOME. Všechno, co načítá váš přihlašovací shell (další položky v PATH, správci verzí, exportované proměnné) chybí. Skript, který funguje, když ho spustíte ručně, pod cronem selže.
2. Znak procenta. Neescapovaný % se v řádku crontabu změní na nový řádek a vše za ním se předá příkazu jako vstup. date +%F v názvu souboru se zálohou tak potichu rozbije celý řádek.
3. Výstup, který nikam nedorazí. Cron posílá výstup úlohy e-mailem vlastníkovi crontabu, případně na adresu v MAILTO. Na většině serverů tu schránku nikdo nečte, nebo se pošta nedoručuje vůbec – chybová hláška tedy existuje, jen ji nikdo neuvidí.
4. Úloha, která nikdy neskončí. Síťové volání bez timeoutu nebo zámek, který po sobě nechal spadlý běh, a úloha visí. Žádná chyba, žádný výstup, prostě nic.
5. Letní čas. Manuál crontab to říká přímo: časy, které při změně neexistují, nikdy nenastanou, takže se úlohy na ně naplánované nespustí, a časy, které nastanou dvakrát, spustí úlohy dvakrát.
6. Rozvrh zmizí. Migrace serveru, znovu sestavený kontejner nebo nový deploy bez crontabu – a úloha prostě přestane existovat.
7. Plánovač platformy není záruka. Dokumentace GitHubu uvádí, že plánované workflow se mohou v obdobích vysoké zátěže zpozdit, že některé úlohy ve frontě mohou být zahozeny a že ve veřejném repozitáři se automaticky vypnou po 60 dnech bez aktivity v repozitáři.

Nic z toho samo o sobě upozornění nevyvolá. To je skutečný problém cronu: selhání vypadá úplně stejně jako úspěch – ticho.

Proč to monitoring dostupnosti nezachytí

Monitoring dostupnosti se vašeho serveru na něco zeptá a zkontroluje odpověď. Cron úloha na otázky neodpovídá: nemá port, ke kterému se připojit, ani stránku, kterou načíst. Selhání, které potřebujete odhalit, je absence – běh, který měl proběhnout, a neproběhl. Všimnout si, že signál nepřišel, dokáže jen něco, co ten signál v daném čase očekává.

Jak funguje heartbeat monitoring

Monitorovací službě řeknete, kdy má úloha běžet – každých 15 minut, nebo podle cron výrazu jako 0 3 * * * – a jaké zpoždění je ještě přijatelné (grace period, tedy tolerance). Úloha při každém úspěšném dokončení pingne unikátní URL. Služba pak ví, v jakém stavu úloha je:

Poslední dva řádky vysvětlují, proč dobré nastavení posílá víc než jeden signál. Ping na konci vám řekne, že úloha doběhla. Ping i na začátku vám řekne, že začala – takže úloha, která se zasekne v půlce, se zachytí a nevypadá jako cron, který se vůbec nespustil. A explicitní ping o selhání spustí poplach hned, místo aby se čekalo na termín.

Jak přidat monitorování ke cron úloze

Nejjednodušší varianta pingne jen po úspěšném běhu. Na && záleží: když úloha selže, ping se vůbec neodešle a po termínu se kontrola označí jako „Vynechaná“.

0 3 * * * /path/to/backup.sh && curl -fsS --retry 3 https://api.alertsleep.com/v1/ping/YOUR-TOKEN

Úplná varianta hlásí start, úspěch i selhání:

0 3 * * * curl -fsS --retry 3 https://api.alertsleep.com/v1/ping/YOUR-TOKEN/start; if /path/to/backup.sh; then curl -fsS --retry 3 https://api.alertsleep.com/v1/ping/YOUR-TOKEN; else curl -fsS --retry 3 https://api.alertsleep.com/v1/ping/YOUR-TOKEN/fail; fi

Dva detaily jsou záměrné. Za startovním pingem je ;, ne &&, takže úloha poběží, i když se ping nepodaří doručit. A řádek používá if/then/else místo oblíbené zkratky job && success || fail, která nahlásí selhání i tehdy, když úloha uspěla a nedorazil jen ping o úspěchu.

Můžete také předat exit code a nechat rozhodnutí na monitorovací službě. Nenulový kód odeslaný na URL pro úspěch se zaznamená jako selhání:

0 3 * * * /path/to/backup.sh; curl -fsS --retry 3 --data "exit_code=$?" https://api.alertsleep.com/v1/ping/YOUR-TOKEN

Volby curl stojí za to ponechat: -f zajistí, že se chyba HTTP počítá jako chyba, -sS mlčí, dokud se něco nepokazí, a --retry 3 přečká krátký výpadek sítě.

Plánovač v Laravelu

Pokud je úloha už naplánovaný příkaz Laravelu, plánovač umí URL zavolat sám – bez escapování v shellu a bez ručního předávání exit codů:

// routes/console.php
Schedule::command('backup:run')
    ->cron('0 3 * * *')
    ->pingBefore('https://api.alertsleep.com/v1/ping/YOUR-TOKEN/start')
    ->pingOnSuccess('https://api.alertsleep.com/v1/ping/YOUR-TOKEN')
    ->pingOnFailure('https://api.alertsleep.com/v1/ping/YOUR-TOKEN/fail');

V Laravelu si pohlídejte ještě jednu věc: celý plánovač závisí na jediném záznamu v crontabu, který každou minutu spouští php artisan schedule:run. Když se tento záznam ztratí, zastaví se najednou všechny naplánované úlohy – a přesně to vám prozradí heartbeat na vaší nejdůležitější úloze.

Plánované workflow v GitHub Actions

Protože plánované workflow se mohou zpozdit, být zahozeny nebo vypnuty, potřebují heartbeat stejně jako server. URL pro ping uložte do secretu repozitáře, zacházejte s ní jako s heslem a přidejte tři kroky:

on:
  schedule:
    - cron: '0 3 * * *'

jobs:
  nightly:
    runs-on: ubuntu-latest
    steps:
      - run: curl -fsS --retry 3 "${{ secrets.ALERTSLEEP_PING_URL }}/start" || true
      - run: ./scripts/nightly.sh
      - if: success()
        run: curl -fsS --retry 3 "${{ secrets.ALERTSLEEP_PING_URL }}"
      - if: failure()
        run: curl -fsS --retry 3 "${{ secrets.ALERTSLEEP_PING_URL }}/fail"

|| true u startovního pingu zajistí, že workflow poběží dál, i když se ping nepodaří doručit. Běh, který GitHub zpozdí za hranici grace period nebo který se vůbec nespustí, se projeví jako chybějící heartbeat – jediné selhání, které workflow samo nikdy nahlásit nemůže.

Jak dlouhá má být grace period?

Dost dlouhá na běžný rozptyl doby běhu, dost krátká na to, aby skutečný problém byl ještě čerstvý. Užitečné pravidlo: vezměte nejdelší běh, který jste viděli, a přidejte rezervu. Záloha, která obvykle trvá 20 až 40 minut, potřebuje zhruba hodinu; úklidové úloze, která trvá pár sekund, stačí pět minut. Pokud se kontrola opakovaně označuje jako „Opožděná“, aniž by bylo něco špatně, je grace period příliš krátká – a upozornění, které je většinou planým poplachem, naučí lidi ho ignorovat.

Jak AlertSleep monitoruje cron úlohy

Cron kontrola v AlertSleep se skládá z rozvrhu a URL pro ping:

• rozvrh je buď interval (od jedné minuty do 30 dnů), nebo cron výraz s vlastním časovým pásmem;
• grace period může být cokoli od 30 sekund do 24 hodin, výchozí hodnota je pět minut;
• URL pro ping přijímá GET, POST i HEAD, má varianty /start a /fail a volitelně i exit code, dobu běhu a krátkou zprávu;
• úloha, která poslala /start a během grace period už nic dalšího, se hlásí jako zaseknutá, ne jako nespuštěná;
• když kontrola selže, přijde upozornění e-mailem a do dashboardu, a po dalším úspěšném pingu následuje oznámení o obnovení;
• každý ping se uchovává i s exit codem a dobou běhu, takže vidíte, kdy úloha začala trvat déle;
• dashboard ke každé kontrole ukazuje připravené úryvky pro crontab a Laravel ke zkopírování a token lze přegenerovat, pokud URL pro ping unikne.

Podrobnosti najdete na stránce monitorování cron úloh. Pokud teprve píšete samotný rozvrh, bezplatný Generátor cron výrazů sestaví výraz z formuláře a vypíše jeho příštích pět spuštění.

Kontrolní seznam pro cron na 20 minut

1. Najděte všechny naplánované úlohy. crontab -l pro každého uživatele, soubory v /etc/cron.d, systemctl list-timers, plánované workflow v CI a případný plánovač uvnitř vaší aplikace.
2. U každé si položte otázku, co se rozbije, když týden nepoběží. Na začátku seznamu bývají zálohy, faktury, synchronizace dat, obnova certifikátů a úklidové úlohy.
3. K těm důležitým přidejte heartbeat – začněte zálohami, protože nefunkční záloha se odhalí až ve chvíli, kdy potřebujete obnovovat.
4. Grace period nastavte podle skutečných dob běhu, ne odhadem.
5. Vyzkoušejte to: jednu úlohu záměrně zastavte nebo ji nasměrujte na špatnou cestu a ověřte, že upozornění dorazí.
6. Escapujte každý % v řádcích crontabu a prostředí, které úloha potřebuje, nastavte explicitně na začátku skriptu.

Časté dotazy

Jaký je rozdíl mezi monitorováním cronu a monitoringem dostupnosti?

Monitoring dostupnosti kontroluje něco, co je k dispozici pořád – web, API, port. Monitorování cronu, a obecně monitorování plánovaných úloh, čeká na signál od něčeho, co běží jen čas od času, a upozorní vás, když signál nepřijde.

Musí být úloha dostupná z internetu?

Ne. Úloha jen odešle odchozí HTTPS požadavek na URL pro ping. K vašemu serveru se nemusí nic připojovat.

Co se stane, když se ping nepodaří doručit?

--retry 3 si poradí s krátkými problémy se sítí. Pokud ping přesto nedorazí, po termínu se kontrola označí jako „Vynechaná“ a dostanete upozornění. Občas to může být planý poplach, ale je to bezpečnější směr: přehlédnuté skutečné selhání stojí mnohem víc než zbytečný e-mail.

Můžu monitorovat úlohy, které běží častěji než jednou za minutu?

Nejkratší interval je jedna minuta. U úloh, které běží častěji, pingejte z úlohy jednou za minutu, nebo monitorujte proces, který je spouští.

Je URL pro ping tajná?

Ano. Kdokoli, kdo ji má, může vaši úlohu nahlásit jako zdravou. Nedávejte ji do veřejných repozitářů, v CI ji uložte do secretu a pokud někdy unikne, token přegenerujte.

Zdroje

• crontab(5) – manuálová stránka Linuxu
• Laravel – Task Scheduling (plánování úloh)
• GitHub Docs – Events that trigger workflows: schedule (události spouštějící workflow)