7 typiske automatiseringsfejl – og sikkerhedsnettene

Kort svar: Automatiseringer fejler sjældent på teknikken – de fejler på manglende sikkerhedsnet. De syv typiske eksempler på automatiseringsfejl i denne artikel koger ned til fem net, ethvert flow bør have: idempotens (samme hændelse må aldrig udløse dobbelt handling), opsamlingstjek (mål resultatet, ikke kørslen), dead man’s switch (alarm når flowet udebliver), mindste privilegium (nøgler kan højst det nødvendige) og backup plus dry-run før alt, der skriver. Tæl selv, hvor mange af nettene dine flows har.

Fagligt gennemgået: 2. oktober 2026

Automatisering kan spare timer hver uge. Men den kan også gå galt – hurtigt, stille og i stor skala. Et flow, der kører forkert om natten, kan nå at ændre hundredvis af ordrer, priser eller mails, før nogen opdager det.

Eksemplerne herunder er typiske fejlscenarier, som de fleste, der drifter integrationer mellem webshop, regnskab, lager og mail, før eller siden møder i en eller anden variant. De er beskrevet som scenarier, ikke som konkrete kundesager. Pointen er mønstergenkendelse: hvert scenarie mangler præcis ét sikkerhedsnet – og alle fem net er billige at sætte op, før du har brug for dem.

Når flowet kører i ring (1–2)

1) Mailløkken. Et flow sender en bekræftelsesmail, når en ordre bliver opdateret. Mailsystemet skriver et lille felt tilbage på ordren (“mail sendt”) – hvilket opdaterer ordren og udløser flowet igen. Kunden får beskeden igen og igen, indtil nogen opdager det.

Nettet, der mangler: idempotens og løkkeværn. Flows, der kan udløse deres egen trigger, skal registrere deres handlinger (“er beskeden for denne hændelse allerede sendt? Så stop”). Vælg samtidig smallere triggere: “status ændret til gennemført” frem for “ordre opdateret”.

2) Dobbeltoprettelsen. Under et skift af bogføringsintegration kører både det gamle og det nye flow i nogle dage. Alt salg bliver bogført to gange og opdages først ved momsafstemningen.

Nettet: én klar ejer pr. opgave under overgange. Parallelkørsel er til at sammenligne resultater, ikke til at lade begge systemer handle – se migreringsguiden fra Zapier til n8n. Tilføj desuden et dubletjek på ordrenummer i alt, der opretter poster.

Når flowet lyver (3–4)

3) Valutaimporten. En leverandør ændrer sit feed fra kroner til euro uden varsel. Importflowet kører grønt hver nat, men indkøbspriserne bliver nu læst som kroner – omkring en syvendedel af det rigtige. Prisreglerne omsætter dem loyalt til salgspriser med negativ margin, og de populære varer sælger pludselig rigtig godt.

Nettet: opsamlingstjek og bremseregler. Mål på resultatet: “er nogen pris ændret mere end X %? Sæt varen på pause til manuel kontrol.” Det er beskrevet i guiden til leverandør-feeds.

4) Den døde webhook. WooCommerce deaktiverer automatisk en webhook, når leveringen er fejlet mere end fem gange i træk. Efter en periode med timeouts hos modtageren holder webhooken stille op – og lagersystemet får ingen salg at vide, før oversalg får nogen til at grave.

Nettet: dead man’s switch. Et flow, der ikke kører, sender ingen fejlbesked; kun udeblevne livstegn afslører det. Sæt en alarm op, der reagerer, når der ikke er kommet data i et tidsrum, hvor der burde være kommet noget. Overvågningsguiden viser hvordan, og guiden til webhooks, der ikke virker forklarer status og leveringslog.

Når mennesket mangler (5–7)

5) Autosvaret på klagen. En skabelonbesked (“Tak for din henvendelse! Se vores FAQ …”) sendes til en kunde, hvis pakke er forsvundet for anden gang. Kunden deler svaret i en offentlig anmeldelse.

Nettet: følelsesfilteret. Klager og skuffede kunder skal sendes videre til et menneske – altid. Kundeservice-guiden tegner grænsen for, hvad der kan automatiseres.

6) Nøglen i kodearkivet. En udvikler committer et hjælpescript med en API-nøgle, der har skriveadgang, til et offentligt kodearkiv. Automatiske scannere leder konstant efter netop den slags lækkede nøgler.

Nettet: mindste privilegium og opbevaringsdisciplin. Nøgler skal kun kunne det nødvendige, ligge i miljøvariabler eller en hemmelighedsboks – aldrig i koden – og kunne roteres hurtigt. Se guiden til API-nøgler og tokens.

7) Oprydningsscriptet. Et script, der skal slette gamle kladder, matcher bredere end tænkt og sletter også rigtige sider. Der er ingen dry-run og ingen frisk backup, så siderne skal genskabes i hånden.

Nettet: backup før alt, der skriver – og en testkørsel, der viser, hvad der rammes, før noget rammes.

Mønstret: de fem sikkerhedsnet

Læg scenarierne ved siden af hinanden, og mønstret står klart: ingen af dem skyldes dårlig teknik – alle skyldes et manglende net, der kunne være sat op på kort tid.

Sikkerhedsnet	Spørgsmålet, du stiller	Forebygger
Idempotens og løkkeværn	Kan samme hændelse udløse dobbelt handling?	Mailløkker, dobbeltordrer, dobbeltbogføring
Opsamlingstjek	Måles der på resultatet – eller kun på grønne kørsler?	Forkerte data, der ser rigtige ud
Dead man’s switch	Opdager vi det, hvis flowet slet ikke kører?	Døde webhooks og stoppede jobs
Mindste privilegium	Kan flowets nøgler højst gøre det nødvendige?	Store skader ved lækkede nøgler
Backup og dry-run	Er der backup og testkørsel før alt, der skriver eller sletter?	Utilsigtede sletninger og masseændringer

Fem spørgsmål, to minutter. Gør dem til en fast del af jeres flowdokumentation, så arver hvert nyt flow disciplinen automatisk.

Sådan sætter du nettene op i praksis

Nettene kræver ikke dyre værktøjer. De fleste kan bygges med det, du allerede har:

• Idempotens: gem et unikt ID for hver behandlet hændelse (fx ordre-ID plus hændelsestype) og spring over, hvis det allerede findes. Mange systemer tilbyder et felt eller en tabel til formålet; ellers kan et ordrenotat eller en metadata-nøgle på ordren bruges.
• Opsamlingstjek: et dagligt kontroljob, der sammenligner tal på tværs af systemer – fx antal ordrer i shoppen mod antal bilag i regnskabet – og sender besked ved afvigelser.
• Dead man’s switch: lad flowet sende et livstegn til en overvågningstjeneste ved hver kørsel. Udebliver livstegnet, kommer alarmen. Mange uptime-tjenester har en sådan “heartbeat”-funktion.
• Fejlhåndtering: automatiseringsplatforme som n8n, Make og Zapier har mulighed for fejlnotifikationer eller særlige fejlflows. Slå dem til, og send beskeden til en kanal, som nogen faktisk læser.
• Mindste privilegium: opret separate nøgler pr. integration med kun de rettigheder, der skal bruges – læseadgang, hvor skriveadgang ikke er nødvendig.

Test, før flowet går i drift

Et nyt flow bør gennemgå tre test, før det får lov at køre på rigtige data:

1. Alle grene med testdata – også fejlgrenene og de sjældne tilfælde, fx en ordre uden fragt eller en kunde uden telefonnummer.
2. Dry-run af alt, der skriver – lad flowet logge, hvad det ville gøre, uden at gøre det.
3. Et fremprovokeret fejlscenarie – hvad sker der, når API’et svarer 500 eller ikke svarer? Får nogen besked, og bliver hændelsen forsøgt igen uden at blive udført to gange?

Skalér indsatsen efter konsekvens. Et flow, der sender en intern notifikation, kan nøjes med fejlbesked. Alt, der rører penge, lager eller kundedata, bør have hele sættet. Automatisering uden sikkerhedsnet er bare fejl med motor på; med nettene er den et stærkt værktøj for selv en lille virksomhed.

Læs også

• Hub: Automatisering og integrationer
• Overvåg dine automatiseringer: hvad sker der, når flowet fejler?
• Integrationssikkerhed: API-nøgler, tokens og mindste privilegium
• WooCommerce webhook virker ikke: status, signatur og leveringslog
• Lagersynkronisering på tværs af kanaler: undgå oversalg
• WooCommerce hosting hos Hostious – daglig backup med selvbetjent gendannelse og dansk support døgnet rundt

Ofte stillede spørgsmål om automatiseringsfejl

Hvad er den hyppigste automatiseringsfejl?

Den stille: flowet, der holder op med at køre eller kører med forkerte data, uden at nogen får besked. Derfor er dead man’s switch og opsamlingstjek de første net, du bør sætte op.

Hvordan tester jeg et flow, før det går i drift?

Med testdata gennem alle grene (også fejlgrenene), en dry-run af alt, der skriver – og et bevidst fremprovokeret fejlscenarie: hvad sker der, når API’et svarer 500? Får nogen besked?

Skal alle flows have alle fem sikkerhedsnet?

Skalér efter konsekvens: notifikationsflows kan nøjes med fejlbesked, mens alt, der rører penge, lager eller kundedata, bør have hele sættet. Spørgsmålet “hvad koster det, hvis dette kører forkert i en uge?” sætter niveauet.

Hvorfor holder en WooCommerce-webhook pludselig op med at virke?

WooCommerce deaktiverer automatisk en webhook, når leveringen er fejlet mere end fem gange i træk, fx på grund af timeouts hos modtageren. Tjek webhookens status og leveringslog, ret årsagen og aktivér den igen – og sæt en alarm op, der opdager udeblevne data.