WatchKlokken 9:14 en mandag morgen oprettede en udvikler i en lille SaaS-virksomhed en sag for at gendanne en kundes database. Så opdagede hun, at den natlige backup havde fejlet i nitten dage. Ingen havde rørt serveren. Intet var brudt sammen højlydt. Jobbet var simpelthen holdt op med at køre — og i overvågning ligner stilhed til forveksling succes.
Jobbet, der fejler uden en lyd
Historien er ubemærkelsesværdig, netop fordi den er så almindelig. Næsten ethvert team har en planlagt opgave, der stille udfører vigtigt arbejde i baggrunden: et database-dump kl. 2 om natten, en faktureringskørsel den første i måneden, en kø-worker, der arbejder sig gennem opgaver, en eksport, der fodrer en partners system. De kører uden opsyn i måneder — indtil de en dag ikke gør.
Når et baggrundsjob stopper, annoncerer det sjældent selv. En container omplaceres og kommer aldrig tilbage. Et deploy ændrer en sti. En afhængighed kaster en exception, der bliver slugt af et tomt `except`. Cron-linjen er der, serveren er oppe, dashboardet er grønt — og arbejdet sker bare ikke. Du opdager det på det værst tænkelige tidspunkt: når du endelig har brug for resultatet.
Hvorfor almindelig overvågning ikke kan se det
Det meste overvågning er bygget op om ting, der svarer, når man banker på. Et website returnerer en statuskode, et API svarer på en forespørgsel, en port accepterer en forbindelse. Du poller dem efter en tidsplan og handler på det, der kommer tilbage.
En natlig backup svarer ikke til nogen. Den har ingen offentlig URL, ingen port, intet at polle. Udefra er det umuligt at se forskel på, om den kørte perfekt eller aldrig kørte. Det er den blinde vinkel — og det er præcis den slags arbejde, hvis fejl forbliver usynlig, indtil den bliver dyr.
Sådan vender heartbeat-overvågning logikken om
Heartbeat-overvågning vender forholdet på hovedet. I stedet for at en monitor rækker ud efter dit job, rækker dit job ud efter monitoren. Når en kørsel er gennemført korrekt, sender den en hurtig HTTP-forespørgsel — et “check-in” eller “ping” — til en unik URL. Tjenesten lærer at forvente det ping efter en tidsplan.
Hvis check-in'et når frem i tide, er alt vel, og du hører ingenting. Hvis det er forsinket eller udebliver, alarmerer tjenesten dig. Udviklere kalder det en “dead man's switch”: fraværet af et signal er signalet. Du stoler ikke længere på, at et job kørte — du får besked i det øjeblik, det ikke gør.
Sådan sætter du det op, så det rent faktisk hjælper
En heartbeat er kun så god som måden, du kobler den på. Opret én heartbeat pr. job frem for at samle flere, så en alarm peger direkte på det, der fejlede. Sæt det forventede interval, så det matcher tidsplanen, og tilføj en frist (grace period), så en kørsel, der er et par minutter langsom, ikke vækker nogen kl. 3 om natten.
Den detalje, der betyder mest: placér check-in'et allersidst i jobbet, efter arbejdet rent faktisk er lykkedes — ikke i starten. Et ping, der affyres før det rigtige arbejde kører, melder gladeligt “sund” om et job, der crasher halvvejs. Send kun ping ved succes, og send alarmen til det team, der ejer jobbet — ikke til en kanal, ingen læser.
Fang stilheden med WatchControl
Det er præcis det hul, WatchControl er bygget til at lukke. Du opretter en heartbeat-monitor, kopierer dens check-in-URL og tilføjer en enkelt curl-linje til slutningen af dit script eller din cron-linje — ingen agent at installere, ingen indgående adgang at åbne. Det virker, hvor end dit job kan lave et HTTP-kald, også servere bag en firewall.
Sæt intervallet og grace-perioden, og WatchControl holder øje med stilheden for dig. I det øjeblik et check-in udebliver, alarmerer den dig på e-mail, webhook eller SMS — og fordi WatchControl er bygget i Danmark og hostet i EU, forlader de check-in-data aldrig EU. Den backup, der fejler i nitten dage, bliver til den backup, du hører om på dag ét.