Heartbeat-monitoring: så vet du när ett cron-jobb tyst slutar köra

Heartbeat-monitoring är push-baserad övervakning: ditt system skickar en ping (ett enkelt HTTP-anrop) till en unik URL varje gång ett jobb körs klart. Om pingen uteblir längre än det förväntade intervallet plus en grace-period, larmar systemet — så du upptäcker att jobbet slutat köra, inte bara att det en gång misslyckades.

Push vs pull: skillnaden mot vanlig uptime-kontroll

Vanlig uptime-monitoring fungerar genom att en extern tjänst regelbundet frågar din tjänst "är du där?" — ett pull-mönster. Det fungerar utmärkt för webbsidor och API:er som alltid ska svara på förfrågningar.

Cron-jobb och bakgrundsprocesser är annorlunda. De körs periodiskt och gör sitt jobb utan att exponera något att fråga. Ett cron-jobb som ska köras varje natt klockan 03:00 har ingenting att pinga vid 03:05 om det redan är klart — eller om det aldrig startade. Det är precis den situationen heartbeat-monitoring är byggd för: jobbet själv rapporterar att det levde, istället för att någon utifrån försöker gissa.

Problemet heartbeat-monitoring löser kallas ibland "tyst fel" — ett jobb som helt enkelt slutar köras, utan att kasta ett fel någonstans någon tittar på. En cron-post som försvinner vid en servermigrering, ett schemaläggningsverktyg som tappar en post, eller en tjänst som pausas och glöms bort. Inget kraschar högljutt. Ingenting syns förrän någon märker att resultatet av jobbet — en rapport, en synkronisering, en backup — helt enkelt uteblivit, ofta veckor senare.

Så fungerar det: ping-URL, förväntat intervall, grace-period

Grundmodellen har tre delar:

1. En unik ping-URL kopplad till ditt jobb, t.ex. https://qre8.io/ping/<token>.
2. Ett förväntat intervall — hur ofta jobbet normalt körs, t.ex. var 60:e minut.
3. En grace-period — extra marginal utöver intervallet innan systemet larmar, för att täcka normal variation i körtid.

Så länge pingen kommer in inom intervallet plus grace-perioden är monitorn "up" (grön). Uteblir pingen längre än så, flippar monitorn till "down" och du får ett larm.

Exempel: en ping sist i cron-jobbet

Det vanligaste mönstret är att lägga ett curl-anrop sist i cron-jobbets kommandorad:

0 3 * * * /usr/bin/backup-script.sh && curl -fsS https://qre8.io/ping/abc123def456

Varför "sist" spelar roll: om pingen låg först i kedjan skulle den bekräfta att jobbet startade — inte att det faktiskt slutfördes. Genom att placera den sist, efter &&, körs pingen bara om backup-script.sh avslutades utan felkod. Ett skript som kraschar halvvägs skickar aldrig sin ping, och monitorn går ner precis som den ska.

-f gör att curl avslutas med felkod om servern svarar med ett HTTP-felstatus, -sS håller output tyst men visar faktiska fel — praktiskt i cron-loggar där du bara vill se problem, inte brus.

Rapportera fel explicit

Att bara vänta ut grace-perioden fungerar, men det betyder att ett jobb som kraschar direkt ändå tar hela grace-perioden innan larmet går. För snabbare upptäckt finns ofta en separat fail-endpoint:

curl -fsS https://qre8.io/ping/abc123def456/fail

Anropa den i skriptets felhantering (till exempel i ett trap-block eller ett except) så flippar monitorn till "down" omedelbart istället för att vänta ut tidsgränsen.

Vanliga fallgropar

För kort grace-period ger falsklarm. Om jobbet normalt tar 2–4 minuter men grace-perioden bara är 1 minut, kommer du få larm för jobb som faktiskt fungerar helt normalt — bara lite långsammare den dagen. Sätt grace-perioden med marginal för den normala variationen, inte för snittfallet.

Ping före kritiska steg. Om du placerar pingen tidigt i skriptet "för säkerhets skull" tappar du hela poängen — monitorn kan visa grönt även om det viktiga steget efteråt misslyckas. Pingen ska komma efter det som faktiskt måste lyckas, inte innan.

Heartbeat-monitoring är ett komplement till uptime-monitoring, inte en ersättning — de bevakar olika sorters fel. Tekniken bygger på samma grundprincip som webhooks: ett HTTP-anrop som skickas när något händer, istället för att någon frågar om det hänt.