Din n8n-instans börjar piggt. Sedan staplas körningsloggarna på. En dag scrollar du igenom sidor av gamla körningar, gränssnittet känns trögt och att hitta ett verkligt fel blir ett tidsödande jobb.
Det här drabbar driftansvariga som i första hand äger upptid, men byråägare som hanterar många kundautomationer känner av det också. Även solo-byggare fastnar i det. Med automatiserad n8n log cleanup behåller du bara de senaste körningarna du faktiskt behöver och raderar resten automatiskt.
Nedan ser du vad workflowet gör, vilka resultat du kan förvänta dig och de praktiska installationsdetaljer som spelar roll i verkligheten.
Så fungerar den här automatiseringen
Hela n8n-workflowet, från trigger till slutlig output:
n8n Workflow Template: Slack- och e-postlarm för rensade körningsloggar
flowchart LR
subgraph sg0["Schedule Flow"]
direction LR
n0@{ icon: "mdi:play-circle", form: "rounded", label: "Schedule Trigger", pos: "b", h: 48 }
n1["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/n8n.svg' width='40' height='40' /></div><br/>Get many executions"]
n2["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/code.svg' width='40' height='40' /></div><br/>Code"]
n3["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/n8n.svg' width='40' height='40' /></div><br/>Delete an execution"]
n4@{ icon: "mdi:swap-vertical", form: "rounded", label: "Set Executions to Keep", pos: "b", h: 48 }
n2 --> n3
n0 --> n1
n1 --> n4
n4 --> n2
end
%% Styling
classDef trigger fill:#e8f5e9,stroke:#388e3c,stroke-width:2px
classDef ai fill:#e3f2fd,stroke:#1976d2,stroke-width:2px
classDef aiModel fill:#e8eaf6,stroke:#3f51b5,stroke-width:2px
classDef decision fill:#fff8e1,stroke:#f9a825,stroke-width:2px
classDef database fill:#fce4ec,stroke:#c2185b,stroke-width:2px
classDef api fill:#fff3e0,stroke:#e65100,stroke-width:2px
classDef code fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px
classDef disabled stroke-dasharray: 5 5,opacity: 0.5
class n0 trigger
class n2 code
classDef customIcon fill:none,stroke:none
class n1,n2,n3 customIcon
Problemet: körningsloggar saktar tyst ner allt
Körningshistorik är användbar … tills den inte är det. Om du kör dussintals (eller hundratals) workflows växer backlogen snabbt och blir brus i stället för signal. Du öppnar ett workflow för att felsöka ett nytt problem och möts av förra månadens körningar. Din databas eller lagring fortsätter att växa. Och n8n-gränssnittet kan börja kännas tungt, särskilt när du filtrerar körningar, öppnar detaljer eller växlar mellan workflows under en hektisk dag.
Det bygger upp snabbt. Här är var det brukar fallera i praktiken.
- Du behåller långt mer historik än du någonsin kommer att granska, eftersom manuell rensning är lätt att glömma.
- Fel begravs, vilket innebär långsammare incidenthantering och längre kundpåverkande driftstopp.
- Lagringen växer utan affärsnytta, och du märker det först när prestandan dippar eller när backuperna blir större.
- Team undviker att kontrollera körningar eftersom det känns långsamt och rörigt, så problem blir kvar.
Lösningen: radera gamla körningar automatiskt (och behåll rätt)
Det här workflowet rensar din n8n-körningshistorik enligt schema, utan att röra databasen direkt och utan några icke-stödda genvägar. Det börjar med en schemalagd trigger (dagligen, veckovis, vad som passar), hämtar sedan en batch med senaste körningarna från din instans via det officiella n8n-API:t. Därefter grupperar det körningarna per workflow och tillämpar din retention-regel: ”behåll de senaste N per workflow”. Allt äldre blir en raderingslista, och n8n tar bort de körningsposterna åt dig. Inga gissningar, inga manuella rensningspass och ingen röra som byggs upp i bakgrunden.
Workflowet startar på en timer. Sedan hämtar n8n upp till 250 senaste körningar, räknar ut vilka som ska behållas och raderar resten. Du styr retention-talet, inklusive ett ”radera allt”-läge genom att sätta det till 0.
Vad du får: automatisering vs. resultat
| Vad detta workflow automatiserar | Resultat du får |
|---|---|
|
|
Exempel: så här ser det ut
Säg att du kör 60 workflows och att varje workflow körs cirka 15 gånger per dag. Det är ungefär 900 nya körningar varje dag. Att manuellt granska och radera gamla körningar tar lätt en timme i veckan, och ärligt talat kommer det ändå inte att hålla sig snyggt eftersom ingen gör det konsekvent. Med det här workflowet som kör dagligen behåller du (till exempel) de senaste 10 körningarna per workflow, och äldre tas bort automatiskt efter att API-hämtningen och rensningslogiken har körts. Du lägger några minuter på att ställa in retention en gång, sedan slipper du tänka på det.
Det här behöver du
- n8n-instans (prova n8n Cloud gratis)
- Alternativ för self-hosting om du föredrar det (Hostinger fungerar bra)
- n8n API-nyckel för autentiserad åtkomst (hämta den i Inställningar → API-nycklar)
- n8n API-inloggningsuppgift för att spara din bas-URL och nyckel
Kunskapsnivå: Nybörjare. Du klistrar in en API-nyckel, sätter ett retention-tal och testar först med begränsad omfattning.
Vill du inte sätta upp detta själv? Prata med en automationsexpert (gratis 15-minuters konsultation).
Så fungerar det
En schemalagd trigger drar igång. Du väljer när den ska köras (dagligen är ett vanligt val). Målet är enkelt: låt inte körningshistoriken växa snabbare än du rensar den.
n8n hämtar senaste körningarna från din egen instans. Med det officiella API:t hämtar workflowet upp till 250 körningar per körning, vilket är API:ts tak. Om du har en instans med hög volym kan du köra detta oftare för att hinna med.
Retention-regler tillämpas per workflow. En Set-nod anger hur många körningar som ska behållas (t.ex. 10). Sedan grupperar Code-logiken körningar per workflow och räknar ut vad som är tillräckligt gammalt för att raderas.
Gamla körningsposter raderas. Workflowet skickar raderingsbegäran tillbaka till n8n-API:t och tar bort de äldre posterna så att din körningsvy hålls fokuserad på det aktuella.
Du kan enkelt justera retention-antalet för att behålla mer historik för kritiska workflows och mindre för ”stökiga” baserat på dina behov. Se hela implementationsguiden nedan för anpassningsalternativ.
Steg-för-steg-guide för implementering
Steg 1: konfigurera den schemalagda triggern
Det här arbetsflödet körs enligt ett tidsstyrt schema för att rensa upp gamla körningar.
- Lägg till noden Scheduled Run Trigger som arbetsflödets trigger.
- Öppna Scheduled Run Trigger och ställ in schemaregeln så att den kör vid
2för Trigger at Hour. - Koppla Scheduled Run Trigger till Retrieve Execution Logs.
Steg 2: anslut n8n API-åtkomst
Arbetsflödet behöver åtkomst till n8n-körningar för att hämta och ta bort loggar.
- Öppna Retrieve Execution Logs och ställ in Resource till
execution. - Ställ in Limit till
250i Retrieve Execution Logs. - Inloggningsuppgifter krävs: anslut era n8nApi-inloggningsuppgifter i Retrieve Execution Logs.
- Öppna Remove Execution Record och ställ in Resource till
executionoch Operation tilldelete. - Ställ in Execution ID till
{{ $json.id }}i Remove Execution Record. - Inloggningsuppgifter krävs: anslut era n8nApi-inloggningsuppgifter i Remove Execution Record.
Steg 3: sätt upp retentions- och rensningslogik
Dessa noder avgör hur många körningar som ska behållas per arbetsflöde och identifierar gamla körningar som ska tas bort.
- Öppna Assign Retention Count och lägg till en tilldelning för executionsToKeep med värdet
10. - Låt Include Other Fields vara aktiverat i Assign Retention Count.
- Öppna Execution Cleanup Logic och klistra in den tillhandahållna JavaScript-koden i JavaScript Code.
- Bekräfta att flödet fortsätter från Assign Retention Count till Execution Cleanup Logic och sedan till Remove Execution Record.
Steg 4: konfigurera borttagningsåtgärden
Gamla körningar som identifieras av rensningslogiken tas bort via n8n API:t.
- Verifiera att Execution Cleanup Logic är kopplad till Remove Execution Record.
- Bekräfta att Remove Execution Record använder Execution ID satt till
{{ $json.id }}för att ta bort den avsedda körningen.
Steg 5: testa och aktivera ert arbetsflöde
Verifiera rensningsbeteendet innan ni aktiverar den schemalagda körningen i produktion.
- Klicka på Execute Workflow för att köra arbetsflödet manuellt från Scheduled Run Trigger.
- Kontrollera utdata från Execution Cleanup Logic för att bekräfta att endast körningar utöver retentionsantalet returneras.
- Verifiera att Remove Execution Record tar bort endast de avsedda körningarna.
- Slå på arbetsflödet till Active för att aktivera schemalagd rensning.
Vanliga fallgropar
- n8n API-inloggningsuppgifter kan gå ut eller få fel scope. Om det slutar fungera, kontrollera Inställningar → API-nycklar och bekräfta sedan att inloggningsuppgiftens bas-URL först innehåller /api/v1.
- Anropet ”Get Many Executions” är begränsat till 250 resultat per körning. Om din instans skapar mer än så mellan rensningarna, kör den oftare annars kommer du fortfarande att uppleva röran.
- Om du sätter retention-värdet till 0 raderas alla hämtade körningar. Testa i en staging-instans eller börja med ett högre tal så att du inte raderar historik du fortfarande behöver för felsökning.
Vanliga frågor
Cirka 20 minuter om din API-nyckel är redo.
Nej. Du sätter ett retention-tal och lägger till en API-inloggningsuppgift i n8n.
Ja. n8n har ett gratis self-hosted-alternativ och en gratis provperiod på n8n Cloud. Cloud-planer börjar på 20 USD/månad för högre volym. Du behöver också räkna in eventuella VPS-hostingkostnader om du self-hostar.
Två alternativ: n8n Cloud (hanterat, enklast att komma igång) eller self-hosting på en VPS. För self-hosting är Hostinger VPS prisvärd och hanterar n8n bra. Self-hosting ger dig obegränsat antal körningar men kräver grundläggande serverdrift.
Ja, men det kräver en liten justering. Noden ”Assign Retention Count” (Set) styr standardantalet att behålla, och noden ”Execution Cleanup Logic” (Code) avgör vad som raderas. Vanliga anpassningar är att behålla fler körningar för intäktskritiska workflows, behålla färre för stökiga test-workflows och att köra rensningen oftare på instanser med hög volym. Om du vill ha olika retention per workflow kan du spara regler per workflow (som en liten mapping) och tillämpa dem i logiken innan radering.
Oftast är det bas-URL:en eller API-nyckeln. Säkerställ att din n8n-inloggningsuppgift använder hela instansens URL med /api/v1 i slutet, och skapa om din personliga API-nyckel om du misstänker att den har återkallats. Om du ligger bakom en proxy, bekräfta att instansen är nåbar från där n8n körs och att anrop till API:t inte blockeras. Kontrollera också användarbehörigheter eftersom vissa roller inte kan nå körnings-endpoints.
Den hämtar upp till 250 körningar per körning (en n8n API-begränsning), så den praktiska kapaciteten beror på hur ofta du schemalägger den och hur belastad din instans är.
För just den här uppgiften, ja. Zapier och Make hanterar inte n8n:s interna körningsposter på ett bra sätt eftersom de ligger utanför din n8n-instans, så du skulle hamna i krångliga workarounds. n8n kan anropa sitt eget API direkt, köra på schema och hantera grupperings-/retentionlogik utan att betala per flerstegsgren. Om du redan lever i Zapier för enkla två-app-zaps, behåll det för det. För n8n-underhåll är det renaste att stanna i n8n. Prata med en automationsexpert om du vill ha hjälp att designa ett bredare underhållsupplägg.
När detta väl körs förblir körningshistoriken användbar i stället för överväldigande. Din instans känns lättare, felsökningen går snabbare och du behöver ingen ”rensningsdag” i kalendern.
Kontakta oss
Hör av dig, så diskuterar vi hur just din verksamhet kan dra nytta av alla fantastiska möjligheter som AI skapar.