Övervakning av cronjobb

Problem med schemalagda uppgifter

En grym egenskap hos cron-jobb är att när de kraschar säger inget det till dig. Webbapplikationen svarar fortsatt på anrop, startsidan ser OK ut, övervakningen lyser grönt – men någonstans på servern har den nattliga backupen inte körts på två veckor. Queue worker har kraschat efter deployment och gamla jobb samlas på hög. Synkronisering varje timme tappar tyst rader på grund av rättighetsproblem. Du får reda på det först när något nedströms till slut går sönder – oftast just när du behöver det som mest. Datateamet vill ha en export, supporten vill ha e-postkö, ops vill ha backup. Då är det redan för sent.

Standardövervakning av uptime fångar inte detta, eftersom det inte finns något att pinga. Cron exponerar inget HTTP-endpoint, öppnar ingen port och startar ingen server. Den startar, avslutar, avslutar. Om den slutar fungera – finns det inga signaler om dess frånvaro förrän du börjar leta.

Omvänt mönster: heartbeat-övervakning

Heartbeat-övervakning (även kallat "dead man's switch" eller "cron-övervakning") vänder på perspektivet. Istället för att vi kontrollerar din tjänst, rapporterar din tjänst in till oss. Du lägger till en rad i din cron – en curl till en unik URL vi genererar – och denna URL sparar en timestamp vid varje anrop. Vi övervakar frånvaron av dessa pingar. Om URL:en inte träffas inom förväntat intervall (plus marginal) behandlar vi det som ett missat körning och skickar en varning.

Modellen är enkel, pålitlig och språkoberoende. Allt som kan göra ett HTTP-anrop – fungerar. Bash via curl, Python via requests, Node via fetch, PHP via curl_init, Task Scheduler i Windows via Invoke-WebRequest, GitHub Actions, Kubernetes CronJobs, Lambda scheduled events – vad som helst. Inget SDK, ingen agent, ingen demon att installera.

Hur du konfigurerar

I DiagnoSEO Uptime Monitoring klickar du på "Lägg till monitor", välj typ "Heartbeat / cron". Verktyget genererar en unik URL med token – t.ex. https://app.diagnoseo.com/tools/uptime-monitoring/hb.php?t=abc123xyz9. Ange önskat intervall (hur ofta jobbet ska köras, i minuter) och marginal (hur sent ett körning får vara innan vi slår larm). Spara.

Ändra nu din cron så den pingar URL:en efter varje lyckad körning. Tre stilar beroende på miljö:

# Bash cron - pinga endast vid framgång
0 3 * * * /usr/bin/backup.sh && curl -fsS https://app.diagnoseo.com/tools/uptime-monitoring/hb.php?t=abc123xyz9 > /dev/null

# Eller när delvis framgång är 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

Från och med nu pingar varje lyckad körning oss, och vi sparar timestampen. Om vi inte ser en ping inom intervall + marginal minuter, skapas en incident och notiser går ut till alla aktiverade kanaler: E-post, Telegram, Slack, Discord, SMS.

Val av intervall och marginal

Intervall ska matcha jobbschemat exakt. Nattlig backup kl 03:00 – intervall 1440 minuter (24h). Synk varje timme – 60. Worker som pollar var 5:e minut – 5.

Marginalen sväljer naturlig jitter. Cron-jobb triggas inte exakt på nanosekunden – de köas, väntar på att föregående körning avslutas, tar back-off vid tillfälliga fel. Ett 24-timmarsjobb med 1 timmes marginal ger en bekväm buffert utan att fördröja varningar. En 5-minuters worker med 2 minuters marginal fångar verkliga krascher snabbt, utan falska positiver från 30-sekunders slumpar. Grovt: sätt marginalen till 10-50% av intervallet beroende på hur "ryckigt" jobbet beter sig.

Mönster vi rekommenderar

• Pinga endast vid framgång. Använd && i bash – misslyckade körningar pingar inte. Vi upptäcker brist på ping och larmar.
• Pinga efter varje loop-iteration. För långtgående workers, pinga inuti loopen efter varje lyckad arbetsenhet, inte i slutet. Då kan vi upptäcka hängda workers mitt under körning.
• En heartbeat per logiskt jobb, inte per skript. Om tre skript tillsammans utgör en nattlig pipeline, pinga en gång i slutet av kedjan. Det ger en tydlig signal om "pipelinen lever".
• Koppla till loggar. Heartbeat visar att jobbet startade. Applikationsloggar säger vad som gjordes. Tillsammans får du hela bilden.

Vad händer om heartbeat försvinner

En incident öppnas vid deadline. Dashboard visar monitorn i rött med felmeddelandet "Ingen heartbeat på X minuter". Notiser går ut till alla kanaler du har aktiverade. När en ny heartbeat anländer återgår monitorn automatiskt till up – den markeras som up, incidenten stängs, och (om du har aktiverat återställningsvarningar) får du notisen "åter online".

Allt detta hanteras precis som andra monitorer – heatmap, uptime-procent, historik, taggar, sökning, export. Från dashboardens perspektiv är en heartbeat-monitor bara ytterligare en rad, sorterbar och filtrerbar bredvid HTTP, ping, port och API.

Checklista

Lägg till monitor → typ Heartbeat → kopiera genererad URL → lägg till i cron / worker / schemaläggare → ställ in intervall och marginal → spara → klart. Nu får du veta direkt om en schemalagd uppgift slutar fungera – vilket på längre sikt är ett av de mest avgörande övervakningsbeslut du kan ta.

Vanliga frågor

• Vad är heartbeat- / cronjob-övervakning?

  Omvänd övervakning — din schemalagda uppgift pingar vår URL när den startar framgångsrikt. Om vi inte hör ifrån den inom förväntat fönster, larmar vi. Det löser tysta fel: ett trasigt cronjobb ger inget fel och triggar ingen traditionell uptime-varning.

• Hur integrerar jag en heartbeat-URL i min cron?

  Lägg till curl -fsS <heartbeat_url> i slutet av crons kommandorad. Om kommandot före misslyckas körs inte curl och heartbeaten hoppas över. Alternativt kan du pinga i början och slutet via olika endpoints – det ger separata signaler för "startat" och "färdigt".

• Vilken grace period ska jag ställa in?

  Ungefär 2-3x den normala körningstiden. Om din dagliga backup tar 30 minuter, ställ in grace till 90 minuter – täcker upp för fördröjningar utan falska larm. För jobb med varierande körtid, ställ in generöst och använd dashboarden för att hitta avvikare.

• Kan jag övervaka cronjobb som körs varje timme?

  Ja – ställ in intervall därefter (t.ex. 60 minuter väntat med 15 minuters grace). Monitorn väntar sig en ping minst var 75:e minut. Om din uppgift är tätare (var 5:e minut) hanterar heartbeat-URL:en detta också – ställ bara in intervallet därefter.

• Funkar heartbeat-övervakning för AWS Lambda/serverless?

  Ja. Lägg till ett utgående HTTP-anrop till heartbeat-URL i slutet av Lambda-funktionen. Monitorn behandlar det precis som en cron-heartbeat – samma varningar, samma grace period. Användbart för schemalagda Lambdas där CloudWatch-larm inte fångar tysta körningsfel.