Overvågning af cronjob

Problem med planlagte opgaver

En grusom egenskab ved cron-jobs er, at når de fejler, får du ingen besked. Webapplikationen serverer stadig requests, forsiden ser OK ud, monitoreringen lyser grønt – men et sted på serveren er nat-backupen ikke kørt i to uger. Queue-worker gik ned efter et deploy, og gamle jobs hober sig op. Timebaseret synkronisering mister tavst rækker på grund af rettighedsproblemer. Du opdager det først, når noget downstream til sidst fejler – typisk netop i det øjeblik, du har allermest brug for det. Data-teamet vil have en eksport, supporten har en mailkø, drift skal have backup. Så er det allerede for sent.

Standard uptime-monitorering fanger det ikke, for der er intet at pinge. Cron eksponerer ikke et HTTP-endpoint, åbner ingen port og starter ingen server. Den starter, slutter, slutter. Hvis den stopper med at virke – er der intet signal om dens fravær, før du begynder at lede.

Omvendt mønster: heartbeat-overvågning

Heartbeat-monitorering (også kaldet "dead man's switch" eller "cron-overvågning") vender retningen om. I stedet for at vi tjekker din service, rapporterer din service til os. Du tilføjer én linje til din cron – curl til en unik URL, vi genererer – og denne URL gemmer et tidsstempel ved hvert ping. Vi holder styr på manglende ping. Hvis URL'en ikke rammes i det forventede interval (plus margin), opfatter vi det som et manglende run og sender en alarm.

Modellen er enkel, pålidelig og sproguafhængig. Alt der kan lave et HTTP-request – kan integreres. Bash via curl, Python via requests, Node via fetch, PHP via curl_init, Task Scheduler på Windows via Invoke-WebRequest, GitHub Actions, Kubernetes CronJobs, Lambda scheduled events – hvad som helst. Uden SDK, uden agent, uden dæmon der skal installeres.

Sådan konfigureres det

I DiagnoSEO Uptime Monitoring klik "Tilføj monitor", vælg typen "Heartbeat / cron". Værktøjet genererer en unik URL med token – noget ala https://app.diagnoseo.com/tools/uptime-monitoring/hb.php?t=abc123xyz9. Angiv det forventede interval (hvor ofte jobbet skal køre, i minutter) og margin (hvor meget forsinkelse er OK, før vi panikker). Gem.

Nu skal du ændre din cron, så den pinger URL'en efter hvert vellykket run. Tre måder afhængig af miljø:

# Bash-cron – ping kun efter succes
0 3 * * * /usr/bin/backup.sh && curl -fsS https://app.diagnoseo.com/tools/uptime-monitoring/hb.php?t=abc123xyz9 > /dev/null

# Eller hvis delvis succes er OK
0 3 * * * /usr/bin/backup.sh; curl -fsS https://app.diagnoseo.com/tools/uptime-monitoring/hb.php?t=abc123xyz9 > /dev/null

# Python
import requests
def main():
    do_the_work()
    requests.get('https://app.diagnoseo.com/tools/uptime-monitoring/hb.php?t=abc123xyz9', timeout=5)

# GitHub Actions
- name: Notify heartbeat
  if: success()
  run: curl -fsS https://app.diagnoseo.com/tools/uptime-monitoring/hb.php?t=abc123xyz9

Fra nu af pinger hvert succesfuldt run os, og vi gemmer tidsstemplet. Hvis vi ikke ser et ping inden for interval + margin minutter, åbnes en hændelse, og notifikationer sendes på alle aktiverede kanaler: E-mail, Telegram, Slack, Discord, SMS.

Valg af interval og margin

Intervallet skal matche job-schedule præcist. Nat-backup kl. 3:00 – interval 1440 minutter (24t). Timebaseret synkronisering – 60. Worker der poller hver 5. min – 5.

Marginen absorberer naturlige udsving. Cron-jobs starter ikke præcist på nanosekundet – de kan køres i kø, vente på et tidligere run afsluttes, eller back-off ved midlertidige fejl. Et 24-timers job med 1 times margin giver en behagelig buffer uden at forsinke alarmer. En 5-minutters worker-poller med 2 minutters margin fanger reelle nedbrud hurtigt, uden false positives fra kortvarige 30 sekunders glitches. Tommelfingerregel: sæt margen til 10-50% af intervallet, efter hvor meget jobbet kan "svinge".

Anbefalede mønstre

• Ping kun ved succes. Brug && i bash – et run der fejler, pinger ikke. Vi detekterer manglende ping og advarer.
• Ping efter hver iteration i en loop. For langvarige workers, ping inde i loopen efter hver vellykket arbejdsenhed, ikke kun til sidst. Så opdages hængende workers under kørslen.
• Én heartbeat per logisk opgave, ikke per script. Hvis tre scripts tilsammen udgør én natlig pipeline, så ping kun en gang til sidst i kæden. Det giver et klart signal "lever pipelinen?".
• Kombinér med logs. Heartbeat fortæller om jobbet blev startet. Applikationslogs fortæller, hvad der blev gjort. Tilsammen giver det hele billedet.

Hvad sker der, når heartbeat mangler

En hændelse oprettes straks efter deadline. Dashboardet viser monitoren med rødt og fejlmeddelelsen "Ingen heartbeat i X minutter". Notifikationer sendes til alle kanaler du har slået til. Når et nyt heartbeat kommer, går monitoren automatisk tilbage til "up" – den markeres som oppe, hændelsen lukkes, og (hvis du har recovery-alerts aktiv) får du besked om "back online".

Det hele fungerer som alle andre monitors – heatmap, uptime-procent, historik, tags, søgning, eksport. Fra dashboards synspunkt er en heartbeat-monitor bare endnu en række, sortér- og filtrerbar på linje med HTTP, ping, port og API.

Tjekliste

Tilføj monitor → type Heartbeat → kopiér genereret URL → tilføj til cron / worker / scheduler → sæt interval og margin → gem → færdig. Nu ved du på sekunder, hvis en planlagt opgave stopper med at virke – og det er på lang sigt et af de vigtigste monitoreringsvalg, du kan træffe.

Ofte stillede spørgsmål

• Hvad er heartbeat- / cron-job-overvågning?

  Omvendt overvågning — din planlagte opgave pinger vores URL, når den kører succesfuldt. Hvis vi ikke hører fra den inden for det forventede tidsrum, sender vi en alarm. Løser problemet med tavse nedbrud: et defekt cron-job giver ingen fejl og udløser ikke traditionel uptime-alert.

• Hvordan integrerer jeg heartbeat-URL med min cron?

  Tilføj curl -fsS <heartbeat_url> til slutningen af cron-kommandoen. Hvis kommandoen før fejler, udføres curl ikke, og heartbeat springes over. Alternativt kan du pinge både i starten og slutningen med forskellige endpoints — så får du separate signaler for "startet" og "færdig".

• Hvilken grace-periode bør jeg vælge?

  Cirka 2-3 gange den normale udførelsestid for opgaven. Hvis din daglige backup tager 30 minutter, sæt grace til 90 minutter – det dækker forsinkelser uden falske alarmer. For opgaver med variabel varighed, vær generøs og brug dashboardet til at identificere outliers.

• Kan jeg overvåge cron-jobs der kører hver time?

  Ja – sæt intervallet derefter (fx 60 minutter forventet, med 15 minutters grace). Monitoren forventer mindst ét ping pr. 75 minutter. Hvis din opgave er hyppigere (f.eks. hvert 5. minut), fungerer heartbeat-URL også – du skal blot matche interval-indstillingen.

• Virker heartbeat-overvågning for AWS Lambda / serverless?

  Ja. Tilføj et udgående HTTP-kald til heartbeat-URL til sidst i din Lambda-funktion. Monitoren behandler det på samme måde som en cron-heartbeat – samme alerting, samme grace-periode. Særligt nyttigt for planlagte Lambdaer hvor CloudWatch-alarmer ikke fanger tavse kørselsfejl.