Kort svar: Automatiserede flows fejler på tre måder – de stopper (og siger det ikke), de kører men gør det forkerte, eller de bliver slet ikke udløst – og alle tre er USYNLIGE, medmindre du bygger øjne på. De tre lag: fejl-notifikationer på hvert flow (platformens error-håndtering), en dead man’s switch på alt planlagt (alarm, når „jeg kørte“-beskeden UDEBLIVER) og et dagligt opsamlings-tjek, der sammenligner virkeligheden på tværs (alle dagens ordrer bogført? alle labels dannet?). Læg dertil alarmdisciplin – få alarmer, som altid betyder handling – så sover både du og automatikken trygt.
Automatiseringens mørke side er stilheden: da mennesket 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 – og ingen vidste det. Denne guide bygger det manglende organ: overvågningen, der gør dine automatiseringer lige så højlydte i fejl, som de er stille i drift.
Type 1: flowet stopper. En node kaster fejl – API’et svarede 500, nøglen udløb, formatet ændrede sig – og kørslen dør midt i. Synligt i platformens log, usynligt alle andre steder. Type 2: flowet kører, men gør det forkerte. Den farligste: 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-fundamentet døde (jf. cron-guiden), eller triggeren mistede sin adgang – og et flow, der aldrig starter, producerer heller ingen fejl. De tre typer kræver hver sit lag – og pointen med lagene er netop, at INGEN af dem kan fange alle tre alene.
Grundreglen: intet flow i produktion uden fejlbesked. I n8n sættes ét fælles error-workflow op, som alle flows peger på – fejler en kørsel, får du straks besked med flow-navn, node og fejltekst i mail eller chat; Make og Zapier har tilsvarende fejlruter og notifikationer. Gør beskeden HANDLINGSBAR: „Bogførings-flowet fejlede på ordre 1234: e-conomic svarede 401“ kan handles på øjeblikkeligt (nøglen!), „der skete en fejl“ kan ikke. Og tænk i GENFORSØG før alarm: forbigående fejl (timeout, 503) bør flowet selv prøve igen et par gange med ventetid, så alarmen kun går ved VEDVARENDE problemer – hos både regnskabsintegrationer og fragtflows er en fejlKØ, der kan gensendes, halvdelen af robustheden.
Fejl-notifikationer fanger ikke type 3 – flowet, der aldrig kørte, sender jo ingen fejl. Løsningen er at vende logikken: hvert planlagt flow slutter med at melde „jeg kørte“ til en heartbeat-tjeneste (flere uptime-tjenester har funktionen indbygget: en URL, der skal pinges fx dagligt) – 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 – hvilket er den eneste pålidelige måde at overvåge noget, der ikke sker. Sæt switchen på de flows, hvis udeblivelse koster: natlige synkroniseringer, rapporter, backupjobs – og på selve automatiseringsplatformen, hvis den er selvhostet: serverens uptime-overvågning er dens dead man’s switch.
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 kontrol-flow, 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 (bør være nul). Afvigelse = besked; nul afvigelse = tavshed. Det er samme princip som regnskabets afstemning – bare automatiseret og dagligt – og det fanger også fejl, der slet ikke kommer fra dine flows: pluginet, der holdt op med at sende webhooks, eller leverandøren, der ændrede format. Ti linjers logik, der har reddet flere regnskaber end nogen anden ide i denne hub.
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: hver alarm skal betyde HANDLING (ellers nedgraderes den til ugentlig oversigt), forbigående fejl håndteres af genforsøg før besked, og hver alarmtype får én runbook-linje: „Bogføringsfejl → tjek nøglen, gensend fra fejlkøen; ingen heartbeat fra natsynk → tjek server X“. Sæt én ugentlig kvartersrutine oveni: kig fejlkøer og logs igennem for MØNSTRE – en fejl, der kommer hver tirsdag, har en årsag med ugedag i. Og skriv, 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 tror på.
Omvendt overvågning: flowet melder „jeg kørte“ til en heartbeat-URL, og alarmen går, når beskeden udebliver. Den eneste pålidelige måde at opdage flows, der slet ikke bliver udløst.
Når du begynder at ignorere dem. Hver alarm skal kræve handling; alt andet samles i en ugentlig oversigt. Genforsøg på forbigående fejl fjerner størstedelen af støjen.
Med et dagligt opsamlings-tjek, der sammenligner resultater på tværs: ordrer mod bogføringer, forsendelser mod labels. Kørsels-status kan være grøn, mens indholdet er galt – mål på virkeligheden.
