Overvåg dine automatiseringer: hvad sker der, når flowet fejler?

Kort svar: Automatiserede flows fejler på tre måder: de stopper uden at sige det, de kører men gør det forkerte, eller de bliver slet ikke udløst. Alle tre er usynlige, medmindre du bygger overvågning på. De tre lag er fejlnotifikationer på hvert flow, en dead man’s switch på alt planlagt (alarm, når „jeg kørte“-beskeden udebliver) og et dagligt opsamlingstjek, der sammenligner resultaterne på tværs af systemer. Læg dertil alarmdisciplin – få alarmer, der altid betyder handling.

Fagligt gennemgået: 2. oktober 2026

Automatiseringens bagside er stilheden. Da et menneske lavede opgaven, opdagede mennesket også fejlen. Nu kører opgaven i baggrunden, og fejlen gør det samme. En integration, der stopper fredag eftermiddag, har mandag morgen efterladt tre dages huller i regnskab, labels eller lagertal – uden at nogen vidste det.

Denne guide bygger det, der mangler: overvågningen, der gør dine automatiseringer lige så højlydte, når de fejler, som de er stille, når de virker.

De tre måder, flows fejler på

Type 1: flowet stopper. Et trin kaster en fejl – API’et svarede 500, nøglen udløb, formatet ændrede sig – og kørslen dør midt i. Det er synligt i platformens log, men usynligt alle andre steder.

Type 2: flowet kører, men gør det forkerte. Den farligste type. Leverandøren ændrede en kolonne, og nu importeres priser i den forkerte valuta. Hver kørsel er „grøn“, og hver kørsel gør skaden større.

Type 3: flowet udløses aldrig. Webhooken blev deaktiveret efter gentagne fejl, cron holdt op med at køre (se cron-guiden), eller triggeren mistede sin adgang. Et flow, der aldrig starter, producerer heller ingen fejl.

De tre typer kræver hver sit lag. Pointen med lagene er netop, at ingen af dem kan fange alle tre alene.

1. Fejlnotifikationer på hvert flow

Grundreglen er enkel: intet flow i produktion uden fejlbesked. I n8n sætter du ét fælles fejl-workflow op med en Error Trigger og peger alle flows på det i deres indstillinger. Fejler en kørsel, får du straks besked med flownavn, trin og fejltekst i mail eller chat. Make og Zapier har tilsvarende fejlhåndtering og notifikationer.

Gør beskeden handlingsbar. „Bogføringsflowet fejlede på ordre 1234: e-conomic svarede 401“ kan der handles på med det samme – det er nøglen. „Der skete en fejl“ kan der ikke.

Tænk i genforsøg før alarm. Forbigående fejl som timeout eller 503 bør flowet selv prøve igen et par gange med ventetid, så alarmen kun går ved vedvarende problemer. Både i regnskabsintegrationer og fragtflows er en fejlkø, hvor fejlede kørsler kan gensendes, halvdelen af robustheden.

Hvad en god alarmbesked indeholder

Felt	Eksempel	Hvorfor
Hvilket flow	„Bogføring af ordrer“	Modtageren ved straks, hvad der er ramt
Hvilket trin	„Opret faktura i e-conomic“	Afgrænser fejlen til ét system
Hvilken post	Ordre 1234	Gør det muligt at gensende præcis den
Fejlkode og tekst	401 Unauthorized	Peger ofte direkte på årsagen
Næste skridt	„Tjek API-nøgle, gensend fra fejlkø“	Runbook-linjen, så alle kan reagere

2. Dead man’s switch på det planlagte

Fejlnotifikationer fanger ikke type 3. Flowet, der aldrig kørte, sender jo ingen fejl. Løsningen er at vende logikken om: hvert planlagt flow slutter med at melde „jeg kørte“ til en heartbeat-tjeneste – flere overvågningstjenester har funktionen indbygget som en URL, der skal kaldes fx en gang i døgnet – og alarmen går, når beskeden udebliver.

Så opdages den døde cron, den deaktiverede webhook og platformen, der gik ned, af fraværet. Det er den eneste pålidelige måde at overvåge noget, der ikke sker. Sæt switchen på de flows, hvor udeblivelse koster: natlige synkroniseringer, automatiske rapporter, backupjob – og på selve automatiseringsplatformen, hvis den er selvhostet. Her er serverens uptime-overvågning dens dead man’s switch.

Sæt tidsgrænsen med lidt luft. Et job, der kører kl. 02, kan godt melde ind kl. 02.10 en travl nat. En grænse på et par timer ud over det forventede tidspunkt giver færre falske alarmer.

3. Opsamlingstjekket

Mod type 2 – flowet, der kører grønt og gør det forkerte – hjælper kun én ting: at måle på resultatet i stedet for på kørslen. Byg ét dagligt kontrolflow, der sammenligner på tværs af systemer:

• antal ordrer i shoppen i går mod antal bogførte salg
• antal afsendte ordrer mod antal dannede labels
• antal varer med negativt lager, som bør være nul
• prisændringer over en vis procent siden sidste import

Afvigelse giver besked, nul afvigelse giver tavshed. Det er samme princip som regnskabets afstemning, bare automatiseret og dagligt. Tjekket fanger også fejl, der slet ikke kommer fra dine egne flows: pluginet, der holdt op med at sende webhooks, eller leverandøren, der ændrede format. Det er få linjers logik med stor effekt.

4. Overvåg kilderne i WordPress og WooCommerce

Mange flows starter i WordPress, og her findes to steder, du bør kigge regelmæssigt, fordi fejl dér ellers forbliver skjulte:

• WooCommerce-webhooks: en webhook, der fejler et antal gange i træk (som standard fem), bliver automatisk deaktiveret. Tjek status og leveringslog under webhook-indstillingerne – se guiden til webhooks, der ikke virker.
• Planlagte handlinger: WooCommerce og mange plugins bruger Action Scheduler til baggrundsopgaver. Forfaldne eller fejlede handlinger er et tidligt tegn på, at cron ikke kører – se guiden til forfaldne planlagte handlinger.

Begge dele kan tjekkes automatisk via WooCommerce’ REST API eller WP-CLI og føjes til det daglige opsamlingstjek.

5. Hold øje med udløbsdatoer og kvoter

Mange flows, der pludselig stopper, gør det af forudsigelige grunde: en API-nøgle eller et adgangstoken udløber, en kvote eller hastighedsgrænse rammes (typisk svar 429), eller et certifikat fornyes ikke. De fejl kan du se komme.

Før en liste over nøgler og tokens med udløbsdato og ejer, og sæt påmindelser god tid før. Brug gerne nøgler med begrænsede rettigheder, så en lækket nøgle gør mindst mulig skade – se guiden til API-nøgler og tokens. Certifikater og domæner hører med i samme kalender, jf. overvågning af udløbsdatoer.

6. Alarmdisciplin og runbooks

Overvågning dør af sine egne alarmer. Får du ti om dagen, og ni er støj, ignorerer du nummer elleve – den ægte. Derfor gælder tre regler:

• Hver alarm skal betyde handling. Ellers nedgraderes den til en ugentlig oversigt.
• Forbigående fejl håndteres af genforsøg, før der sendes besked.
• Hver alarmtype får én runbook-linje, fx „Bogføringsfejl: tjek nøglen, gensend fra fejlkøen. Ingen heartbeat fra natsynk: tjek serveren.“

Sæt et ugentligt kvarter af til at gennemgå fejlkøer og logs for mønstre. En fejl, der kommer hver tirsdag, har en årsag, der hænger sammen med ugedagen. Skriv også, hvem der reagerer, ind i jeres beredskabsplan. Overvågning uden ejer er bare dokumenteret forsinkelse. Målet er ro: få, ægte alarmer til én ansvarlig – og ellers stilhed, du kan stole på.

Kører dine flows på en egen server, er stabil drift af selve serveren en forudsætning for alt andet. Hostious tilbyder VPS hosting, der tilpasses efter behov, med dansk support døgnet rundt.

Læs også

• Hub: Automatisering og integrationer
• Planlagte opgaver, der bare kører: cron uden wp-cron-fælder
• Forbind WooCommerce med e-conomic
• 7 automatiseringer, der gik galt – og sikkerhedsnettene, der mangler
• Selvhostet n8n på en VPS: opsætning, sikkerhed og priser
• VPS hosting hos Hostious – tilpasses efter behov

Ofte stillede spørgsmål om overvågning af flows

Hvad er en dead man’s switch?

Omvendt overvågning: flowet melder „jeg kørte“ til en heartbeat-URL, og alarmen går, når beskeden udebliver. Det er den eneste pålidelige måde at opdage flows, der slet ikke bliver udløst.

Hvor mange alarmer er for mange?

Når du begynder at ignorere dem. Hver alarm skal kræve handling, og alt andet samles i en ugentlig oversigt. Genforsøg på forbigående fejl fjerner en stor del af støjen.

Hvordan fanger jeg flows, der kører, men regner forkert?

Med et dagligt opsamlingstjek, der sammenligner resultater på tværs, fx ordrer mod bogføringer og forsendelser mod labels. Kørselsstatus kan være grøn, mens indholdet er forkert, så mål på virkeligheden.

Hvorfor stopper min WooCommerce-webhook af sig selv?

WooCommerce deaktiverer automatisk en webhook, der fejler et antal gange i træk, som standard fem. Find årsagen i leveringsloggen, ret modtageren, og aktivér webhooken igen – og læg en dead man’s switch på flowet, så det opdages næste gang.