Hvad vi lærte da en automation gik ned, og hvad vi ændrede bagefter

I maj 2026 gik et af vores produktionsworkflows stille ned. Det stoppede med at gøre, hvad det skulle, og vi opdagede det 41 timer senere.

Det er den slags fejl, der ikke burde ske. Og den slags fejl, der lærer dig mest.

Hvad var workflowets opgave?

Workflowet hentede dagligt data fra en ekstern API, normaliserede det, og skubbede det videre til en intern database der fodrede et rapporteringssystem. Simpel datapipeline. Kørte stabilt i fire måneder.

Så holdt det op med at hente data.

Hvad så symptomerne ud som?

Fra brugerens perspektiv: rapporterne stoppede med at opdatere. Tallene i dashboardet var fra 41 timer tilbage. For at opdage det skulle man aktivt sammenligne med kildesystemet.

Ingen alarm gik. Ingen fejlmail kom. Workflowet kørte teknisk set stadig, gennemfyldte alle trin, men returnerede tomme datasæt, som det stille behandlede.

Hvad der gik galt

Den eksterne API havde ændret sin paginerings-logik. Tidligere returnerede de data page-by-page med et next_page-token. Nu returnerede de et cursor-baseret system. Vores workflow håndterede ikke det nye format. Det tjekkede for next_page, fandt det ikke, og konkluderede at der ingen data var.

Alt data returneret siden API-opdateringen var stille ignoreret.

Hvornår skiftede de? Vi fandt det ud til sidst: 41 timer og 23 minutter inden vi opdagede det. De havde sendt en e-mail til API-brugere. Den endte i spam.

Hvad vores monitoring ikke fangede

Det er her det bliver interessant og ærligt ubehageligt.

Vi havde monitoring sat op. Vi modtog besked, hvis workflowet fejlede med en fejlkode. Vi modtog besked, hvis det ikke kørte.

Vi modtog ikke besked, hvis det kørte uden fejl men returnerede nul resultater.

Det er en fejltype, der er sværere at opdage end "systemet er nede": systemet kører, men gør ingenting.

Hvad ændrede vi i alle efterfølgende builds?

Ændringen tog to timer at implementere på det specifikke workflow. Det der tog mere tid og var mere værd, var at gå gennem alle vores øvrige produktionsworkflows og anvende de samme tre regler systematisk.

Regel 1: Mål output, ikke kun kørsel

For ethvert workflow der henter eller producerer data: tilføj en eksplicit check på om output er inden for forventet interval. Eksempler:

• Et workflow der henter ordrer bør aldrig returnere nul ordrer i en periode, hvor der historisk altid er ordrer
• Et workflow der genererer en rapport bør aldrig generere en tom rapport
• Et workflow der synkroniserer kontakter bør adskille "ingen nye kontakter" fra "API returnerede ingenting"

Implementer det som en betingelse: hvis output_count == 0 og expected_output > 0, send alarm.

Regel 2: Byg eksplicitte API-version-checks

Hvis du kalder en ekstern API, dokumentér hvilken version du er testet mod. Tilføj en check i workflowet, eller i en separat daglig test, der verificerer at API-responsen stadig har den forventede struktur.

En simpel assertion: "forventede feltet items i API-response. Fandt det ikke. Alarm." Det ville have fanget vores fejl inden for et minut af API-opdateringen.

Regel 3: Adskil "ingen data" fra "fejl ved hentning"

Det lyder indlysende. Det er det ikke altid i praksis.

I vores workflow returnerede API'en teknisk set et gyldigt svar, bare et tomt et. Vi behandlede ikke tomme svar som potentielt fejlagtige. Vi behandlede dem som legitime "ingen nyheder"-tilstande.

Nu er reglen: ethvert tomt svar fra en ekstern datakilde kræver en eksplicit begrundelse. Enten er der dokumenteret historisk præcedens for tomme perioder, eller der sendes en lav-prioritets alarm til menneskelig review.

Hvad overser man altid? API-changelog-tracking

Vi abonnerer nu aktivt på changelog-feeds og release notes fra alle API'er vi er afhængige af i produktionssystemer. Det lyder som overhead, men det er 10 minutters opsætning og en ugentlig e-mail at scanne.

De fleste API-leverandører sender ændringsnotifikationer. Problemet er, at de sender dem til den e-mailadresse, der blev brugt ved API-nøgle-oprettelsen. Det er sjældent en aktiv adresse. Løsning: opret en dedikeret e-mailadresse (f.eks. api-changes@jeres-domæne.dk) og brug den ved alle API-tilmeldinger.

Hvad fortæller vi kunder nu, som ikke var klart dengang?

Vi er mere direkte om dette end vi var tidligere: en automation er ikke et afsluttet projekt. Det er et system i et miljø, der ændrer sig.

API'er opdateres. Dataformater ændres. Platforme indfører breaking changes med eller uden varsel. Det er normalt.

Det ændrer ikke vores tilgang til hvad vi bygger. Men det ændrer hvad vi siger til kunder om, hvad de kan forvente.

Den fulde pris på en automation inkluderer monitoring der faktisk fanger det der kan gå galt, herunder de fejl der ikke producerer en fejlkode. Og det inkluderer en plan for hvad der sker, når noget ændrer sig.

De tre regler i kort form

1. Mål output, ikke kun kørsel: tomme resultater er ikke nødvendigvis korrekte resultater
2. Byg API-version-checks: ved hvad du forventer, alarm hvis strukturen ændres
3. Adskil "ingen data" fra "fejl": lav-prioritets alarm ved uventede tomme svar

Alle tre kan implementeres på et eftermiddag på et eksisterende workflow. Vi anbefaler at gennemgå ét workflow om måneden systematisk. Det er den realistiske kadence for de fleste SMV'er.

Vi er glade for at kigge på jeres specifikke setup og vurdere monitoring-dækning. Det er typisk en halv dags arbejde, og det er sjælefreden værd.

Kilder og metode

Alle tekniske detaljer i denne artikel er fra OCHOs egne projekterfaring (2025-2026). Klientdata er anonymiseret. Ingen identificerbare oplysninger om kunder eller specifikke systemer er videregivet.