Fejlhåndtering i n8n: Sådan bygger du workflows der aldrig fejler stille

Workflow kører

Workflowet kører, men det betyder ikke nødvendigvis, at opgaverne bliver løst korrekt. En grøn indikator i n8n betyder blot, at workflowet er aktivt, ikke at det fungerer fejlfrit. Derfor skal fejlhåndtering være en fast del af opsætningen, ikke noget du først tænker på, når noget går galt.

1) Error Trigger workflow: Opret ét dedikeret ‘Error Catcher’ workflow

Et godt første lag i n8n er et dedikeret workflow, der starter automatisk, når et andet workflow fejler. I stedet for at opdage fejlen ved et tilfælde dagen efter, får du besked med det samme.

Opbygningen er enkel. Du opretter et nyt workflow, som du kalder Error Catcher. Derefter går du ind i indstillingerne for hvert af dine produktionsworkflows og vælger dette workflow under Error Workflow. Fra det øjeblik vil en fejl trigge Error Catcher med det samme.

Dette ene workflow skal gøre tre ting.

Det skal sende en besked i Slack med workflow navn, fejlbesked og præcist tidspunkt. Det skal maile den ansvarlige person, så vedkommende ikke er afhængig af at tjekke chat. Og det skal skrive en linje i et Google Sheet, så du får en historik over, hvad der går galt, og hvor ofte.

En webshop, der importerer 24 produkter om dagen helt automatisk, har ikke råd til, at en fejl i leverandørdata stopper flowet uden at nogen opdager det.

Med Error Catcher ved teamet præcis, hvilket workflow der er stoppet, og kan gå ind og rette med det samme. Byg kun ét sådant workflow og genbrug det på tværs af alle flows. Så ved du altid, hvor fejlmeddelelserne lander.

Grøn: Alt kører, ingen fejl

Grøn status er et godt tegn, men den fortæller ikke hele historien. Målet er, at workflowet både kører og siger tydeligt fra, når data, API svar eller validering begynder at skabe problemer.

Test ikke kun ‘den glade vej’

De fleste fejl opstår ikke, når data flyder perfekt, men når et API går i stå, en rate limit rammer eller et felt indeholder ugyldige værdier. Hvis du kun tester den glade vej, får du hurtigt en falsk tryghed.

En tom response er ikke det samme som en succes.

I vores case med produktimport fra leverandørdata til WooCommerce håndterer flowet dagligt 24 produkter helt automatisk. Hvis leverandørens API svarer med timeout eller returnerer duplikeret data, skal automationen ikke stoppe, men springe posten over og logge fejlen til manuel gennemgang. Uden denne sikkerhedsventil risikerer du enten at oprette dubletter eller at miste en hel dags produkter.

Ugyldige data skal afvises tidligt, ikke sent.

Spørg altid: Hvad sker der ved API timeout? Hvad sker der ved ugyldige data? Hvad sker der ved duplikeret data? Hvad sker der ved tom response? Hvad sker der ved rate limit? Svarene skal ikke være undskyldninger bagefter, men konkrete forgreninger i workflowet. Når fejlscenarier er testet på forhånd, bliver der mindre nedetid og mindre manuel fejlretning.

Sæt altid Error Trigger workflow op

Uanset hvor simpelt et workflow virker, skal det altid have et Error Trigger workflow tilknyttet. Det tager kort tid at konfigurere og kan spare dig for lang fejlsøgning og tabte data.

Byg fejlhåndtering ind fra første node

Fejlhåndtering skal med fra starten. Når du bygger et nyt workflow, bør du aktivere ‘Continue on Fail’ eller ‘Error Output’ på kritiske nodes. Det er sværere at tilføje fejlhåndtering bagefter, når workflowet bliver større.