Behöver ert företag hjälp med att implementera AI? Kontakta oss och få prisoffert här →
AI Skolan ›
januari 22, 2026

Redis + Google Sheets: stoppa dubbla körningar

Rickard Andersson Partner, Nodenordic.se

Ditt arbetsflöde körs två gånger. Sedan tre. Plötsligt har Google Sheets dubbla rader, Google Drive har flera kopior av samma dokument och du lägger tid på att lista ut vilken körning som var den “riktiga”. Det är den typen av röra som gör att du slutar lita på din egen automation.

Den här Redis lock-automationen slår hårt mot marketing ops-team, men även byråbyggare och produktteam som kör interna verktyg känner av den. När din automation bara kan köra en instans åt gången stoppar du spammen och du stoppar tyst datakorruption.

Den här guiden visar vad arbetsflödet gör, vilka resultat du kan förvänta dig och hur du kopplar in det i din n8n-setup så att dubbletttriggers inte förstör dina Sheets (eller ditt tålamod).

Så fungerar automationsflödet

Här är hela arbetsflödet som du kommer att sätta upp:

n8n Workflow Template: Redis + Google Sheets: stoppa dubbla körningar

Varför det här spelar roll: dubblettkörningar som spammar Sheets och Drive

De flesta problem med “dubblettkörningar” ser inte dramatiska ut i början. Det är ett webhook-återförsök, en otålig användare som klickar två gånger eller två scheman som överlappar med några minuter. Sedan kör ditt långa jobb parallellt, båda instanserna skriver till Google Sheets, båda skapar filer i Google Drive, och nu har du dubbla poster, totalsummor som inte stämmer och trasiga nedströmsrapporter. Ännu värre: Google-API:er kan börja rate-limita dig, så felen känns slumpmässiga. Den mentala belastningen är påtaglig eftersom du inte kan avgöra om automationsflödet fallerar… eller bara krockar med sig självt.

Det eskalerar snabbt. Här är hur det brukar fallera i riktiga team.

  • Du får lägga tid på att rensa dubblettrader i Google Sheets efter varje intensiv dag.
  • Parallella körningar kan skapa flera Google Docs eller Drive-mappar, och du märker det först när en kund frågar vilken länk som är korrekt.
  • Rate limits dyker upp vid sämsta möjliga tillfälle eftersom överlappande anrop dubblerar din API-trafik.
  • Återförsök och omkörningar blir riskabla, eftersom du aldrig vet vad som redan har skrivit data.

Vad du bygger: ett Redis-lås + statusgate för långkörande jobb

Det här arbetsflödet lägger till en enkel regel: “bara en körning åt gången” för vilket långkörande jobb som helst i n8n. Det startar när ett annat arbetsflöde anropar det (via en Execute Workflow Trigger) och skickar in en åtgärd som get, set eller unset, samt en unik nyckel för jobbet. Om nyckeln redan är låst i Redis stoppar arbetsflödet tidigt och returnerar ett tydligt fel, i stället för att låta en andra instans kollidera med Google Sheets eller Drive. Om inget lås finns sätter det ett lås med en time-to-live (standard är cirka 10 minuter), uppdaterar lättlästa statuslägen som “working” och “finishing”, och tar sedan bort låset i slutet så att nästa körning kan starta rent.

Flödet börjar med routing (via en Switch) för att avgöra om du ska kontrollera status, sätta låset eller ta bort det. Redis fungerar som single source of truth för “upptagen” kontra “ledig”, medan Wait-noder representerar den långsamma delen av jobbet som du ersätter med ditt riktiga arbete. Till sist svarar arbetsflödet tydligt, så att uppströms arbetsflöden kan hantera “upptagen” på ett förutsägbart sätt.

Det här bygger du

Förväntade resultat

Säg att ditt huvudflöde kör en tung synk som skapar ett Google Doc, lägger det i en Drive-mapp och skriver en sammanfattningsrad till Google Sheets. Det är kanske 10 minuters arbete från start till mål. Utan lås kan två triggers nära varandra dubbla API-anropen och du lägger cirka 30 minuter i veckan på att städa dubbletter och skicka länkar igen. Med det här arbetsflödet sätter den första körningen Redis-låset på sekunder, den andra körningen avslutas direkt med status “upptagen”, och du håller dina Sheets och Drive prydliga med i princip ingen manuell efterstädning.

Innan du börjar

  • n8n-instans (prova n8n Cloud gratis)
  • Alternativ för self-hosting om du föredrar det (Hostinger fungerar bra)
  • Redis för att lagra lås- och statusnyckeln.
  • Google Sheets för att validera utfallet “inga dubbla skrivningar”.
  • Redis-inloggningsuppgifter (skapa dem i n8n Credentials).

Kunskapsnivå: Nybörjare. Du kopplar främst upp credentials och väljer en jobbnyckel och timeout.

Vill du att någon bygger detta åt dig? Prata med en automationsexpert (gratis 15-minuters konsultation).

Steg för steg

Ett föräldraflöde triggar körningen. Den här mallen är byggd för att anropas av ett annat n8n-arbetsflöde via Execute Workflow. Föräldern skickar action (get, set, unset), en key (din jobbidentifierare) och valfritt en timeout i sekunder.

Arbetsflödet routar baserat på action. En Switch-nod skickar exekveringen nedför rätt väg: hämta aktuell status, skriva lås/status-nyckeln eller ta bort den. Det betyder att du kan återanvända samma arbetsflöde både som grindvakt och som statuskontroll.

Redis avgör om jobbet kan fortsätta. Arbetsflödet läser och skriver en Redis-nyckel med namn som process_status_<key> med en TTL (standard cirka 600 sekunder). Om nyckeln redan finns stoppar en If-nod körningen tidigt med Stop and Error, vilket skyddar Google Sheets, Google Drive och allt annat nedströms.

Statusuppdateringar sker under den långsamma delen. Wait-noder står in för dina långkörande steg. Mellan väntetiderna kan arbetsflödet uppdatera statusflaggor som “loading” eller “finishing”, så att ett annat arbetsflöde kan polla med action=get och visa progress.

Du kan enkelt justera statusvärdena så att de matchar din process (till exempel “syncar sheets” eller “skapar docs”) utifrån dina behov. Se den fullständiga implementationsguiden nedan för anpassningsalternativ.

Steg-för-steg-guide för implementation

Steg 1: konfigurera triggern för underworkflow

Det här workflowet är utformat för att anropas av andra workflows och använder en trigger för underworkflow med definierade indata för kontroll av samtidighet.

  1. Lägg till noden Sub-Workflow Trigger Inbound som er startpunkt.
  2. Ställ in Workflow Inputs så att den inkluderar action, value, key och timeout så att de matchar triggerns indata.
  3. Behåll valfritt Manual Test Launcher för lokal testning under uppsättning (inte ansluten till produktionsflödet).

Steg 2: konfigurera routning av åtgärd och tilldelning av timeout

Workflowet tilldelar en standard-timeout och routar exekveringen utifrån inkommande action (get/set/unset).

  1. I Assign Timeout ställer ni in Include Other Fields till true och lägger till en tilldelning för timeout med värdet 600.
  2. Koppla Assign Timeout till Route by Action.
  3. I Route by Action konfigurerar ni regler så att leftValue är {{ $json.action }} och routar till utgångarna get, set respektive unset.

Steg 3: anslut Redis för samtidighetsstatus

Workflowet använder Redis för att lagra och läsa processstatus per nyckel.

  1. Konfigurera Fetch Redis Key med Operation satt till get och Key satt till =process_status_{{ $json.key }}.
  2. Inloggningsuppgifter krävs: Anslut era Redis-inloggningsuppgifter i Fetch Redis Key.
  3. Konfigurera Write Redis Key med Operation satt till set, Key satt till =process_status_{{ $json.key }}, Value satt till ={{ $json.value }} och TTL satt till ={{ $json.timeout }}.
  4. Inloggningsuppgifter krävs: Anslut era Redis-inloggningsuppgifter i Write Redis Key.
  5. Konfigurera Remove Redis Key med Operation satt till delete och Key satt till =process_status_{{ $json.key }}.
  6. Inloggningsuppgifter krävs: Anslut era Redis-inloggningsuppgifter i Remove Redis Key.
  7. Koppla Write Redis Key och Remove Redis Key till Mark Continue för att returnera en success-flagga.

Tips: Säkerställ att ert Redis-nyckelmönster är konsekvent mellan anropare genom att alltid skicka samma key-värde för att undvika kollisioner.

Steg 4: konfigurera anrop till underworkflow och statuskontroller

Det här workflowet använder flera executeWorkflow-noder för att hantera läsning och skrivning av status. Konfigurera dem utifrån funktion snarare än individuellt.

  1. För alla Run Sub-Workflow Config-noder (12 totalt) väljer ni mål-workflow i workflowId och behåller input mapping-schemat enligt definition.
  2. Säkerställ att “get”-operationerna använder indata som key: some_workflow_key och action: get (till exempel i Run Sub-Workflow Config 1, Run Sub-Workflow Config 4, Run Sub-Workflow Config 7, Run Sub-Workflow Config 12).
  3. Säkerställ att “set”-operationerna använder indata som action: set och value: working, started, loading eller finishing (till exempel Run Sub-Workflow Config 2, Run Sub-Workflow Config 5, Run Sub-Workflow Config 9, Run Sub-Workflow Config 10, Run Sub-Workflow Config 11).
  4. Säkerställ att “unset”-operationerna använder indata som action: unset (till exempel Run Sub-Workflow Config 3, Run Sub-Workflow Config 6, Run Sub-Workflow Config 8).
  5. Koppla statuskontroller: Run Sub-Workflow Config 1 → Check Output Empty A, Run Sub-Workflow Config 4 → Check Output Empty B och Run Sub-Workflow Config 7 → Check Output Empty C.

Steg 5: lägg till fördröjningar och statusroutning

Fördröjningsnoder och statusroutning säkerställer väntelägen och statusövergångar.

  1. Koppla No-Op Placeholder till Delay Step A och Delay Step A till Run Sub-Workflow Config 6.
  2. Koppla Run Sub-Workflow Config 9 → Delay Step B → Run Sub-Workflow Config 11 → Delay Step C → Run Sub-Workflow Config 10 → Delay Step D → Run Sub-Workflow Config 8.
  3. Koppla Run Sub-Workflow Config 12 till Route by Status och ställ in regler för started, loading och finished med {{ $json.output }}.

⚠️ Vanlig fallgrop: Om en statussträng inte matchar started, loading eller finished, routas den till fallback-utgången extra i Route by Status.

Steg 6: lägg till felhantering

Workflowet blockerar samtidiga körningar genom att stoppa med ett fel när en process redan körs.

  1. I Check Output Empty B kopplar ni false-grenen till Abort With Error A.
  2. I Check Output Empty C kopplar ni false-grenen till Abort With Error B.
  3. Ställ in Error Message i både Abort With Error A och Abort With Error B till Already Executing.

Steg 7: testa och aktivera ert workflow

Verifiera att samtidighetsvakten läser och skriver Redis-nycklar korrekt innan ni går live.

  1. Använd Manual Test Launcher eller anropa Sub-Workflow Trigger Inbound från ett annat workflow med exempelindata (t.ex. action: get, key: some_workflow_key).
  2. Bekräfta att en lyckad körning sätter Mark Continue med ok: true och att Redis-nycklar skapas/tas bort som förväntat.
  3. Trigga en andra körning med samma nyckel och bekräfta att den stoppar med Already Executing via Abort With Error A eller Abort With Error B.
  4. När testerna passerar, slå om workflowet till Active för användning i produktion.
🔒

Lås upp fullständig steg-för-steg-guide

Få den kompletta implementeringsguiden + nedladdningsbar mall

Felsökningstips

  • Redis-credentials kan löpa ut eller peka på fel databasindex. Om saker skapar fel, kontrollera Redis-credential-inställningarna i n8n först, och bekräfta sedan att nyckeln skrivs där du förväntar dig.
  • Om du använder Wait-noder eller extern bearbetning varierar körtider. Höj TTL/timeout så att låset inte löper ut mitt i jobbet och släpper igenom en andra körning.
  • Stop and Error är bra för tydlighet, men kan se ut som ett “fel” i övervakning. Om teamet vill ha notifieringar, byt felvägen mot Slack/e-post och returnera ett vänligt svar som “upptagen, försök igen”.

Nästa steg

Om du vill ha samma låsmönster men också behöver notifieringar när dubbletter blockeras passar Redis + Slack-notiser för att förhindra dubbla schemalagda körningar bra ihop med det här upplägget, eftersom det gör “upptagen” till ett meddelande som teamet faktiskt ser.

För team som routar leads eller formulärinskick via Zapier är Redis + Zapier: förhindra duplicerade webhook-uppdateringar en praktisk följeslagare. Den hjälper när dubbletttriggern sker utanför n8n och du ändå vill ha en enda källa till sanning.

Behöver du mer insyn än bara “upptagen/ledig”? När du vill ha en körlogg plus en status-historik under körning lägger Redis + Google Sheets: spåra körningar, undvik dubbletter till ett rapporteringslager så att du kan granska vad som hände utan att gräva i exekveringar.

När trafiktoppar skapar bråkiga larm (tänk incident-pings eller övervaknings-webhooks) är Redis + Slack: stoppa dubblettlarm vid trafiktoppar ett bra nästa bygge. Samma låsidé, annan smärta.

Slutligen, om ditt huvudproblem är missbrukande eller överaktiva användare som hamrar ett formulär eller en endpoint, flyttar Redis + Airtable: blockera bråkiga användare, håll data snabb mönstret mot throttling och att hålla din databas strukturerad.


Snabbreferens:

Snabba svar

Hur lång är uppsättningstiden för den här Redis lock-automationen?

Cirka 30 minuter om Redis redan går att nå från n8n.

Krävs det kodning för den här lås-automationen?

Nej. Du konfigurerar credentials, ett nyckelnamn och din föredragna timeout. Logiken är redan byggd med standardnoder i n8n.

Är n8n gratis att använda för det här arbetsflödet för Redis lock-automation?

Ja. n8n har ett gratis self-hosted-alternativ och en gratis testperiod på n8n Cloud. Cloud-planer börjar på 20 USD/månad för högre volym. Du behöver också räkna in kostnaden för Redis-hosting (ofta 5–20 USD/månad beroende på leverantör och krav på drifttid).

Var kan jag hosta n8n för att köra den här automationslösningen?

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 obegränsade exekveringar men kräver grundläggande serveradministration.

Kan jag modifiera det här arbetsflödet för Redis lock-automation för olika användningsfall?

Ja, och det bör du. De flesta börjar med att ändra TTL i steget “Assign Timeout” / timeout set så att den matchar verklig jobblängd, och sedan byta namn på progressvärdena som skrivs till Redis (“working”, “loading”, “finishing”) så att en status-sida blir begriplig. Du kan också ersätta Stop and Error-noderna med ett Slack-meddelande eller ett “försök igen efter”-svar, beroende på hur artig du vill vara mot anropare. Om du behöver separata lås för separata uppgifter ändrar du bara nyckelnamngivningsmönstret så att varje jobb får sin egen Redis-nyckel.

Varför misslyckas min Redis-anslutning i det här arbetsflödet?

Oftast beror det på att Redis host/port, lösenord eller TLS-inställning är fel i n8n-credentials. Det kan också vara nätverksåtkomst (din Redis-server tillåter bara lokal trafik) eller fel databasindex, vilket gör att det ser ut som att nycklar “inte sparas”. Kontrollera anslutningen från din n8n-host först och bekräfta sedan att arbetsflödet kan läsa tillbaka nyckeln som det precis skrev.

Vilken volym kan det här arbetsflödet för Redis lock-automation hantera?

Mycket, eftersom varje anrop i princip bara är en snabb Redis-läsning/-skrivning plus din jobbtid. På n8n Cloud begränsas du främst av planens månatliga exekveringar, och på self-hostad n8n av serverkapaciteten. I praktiken är själva låskontrollen nästan omedelbar, så volymfrågan blir: hur länge kör ditt långjobb, och hur många unika nycklar du använder.

Är den här Redis lock-automationen bättre än att använda Zapier eller Make?

Ofta, ja. n8n gör mönstret enkelt eftersom du kan förgrena, stoppa körningar tydligt och self-hosta för hög volym utan att betala per liten delsteg. Zapier och Make kan hantera deduplicering i enkla fall, men riktig kontroll för “bara en körning åt gången” är svårare när du behöver statuskontroller, egna nycklar och förutsägbar felhantering. Om ditt flöde hanterar Google Sheets, Google Drive och HTTP-anrop i samma körning är den extra kontrollen värd det. Prata med en automationsexpert om du vill ha hjälp att välja det enklaste alternativet för din stack.

Sätt låset en gång, och överlappande körningar slutar vara ditt problem. Dina Google Sheets förblir pålitliga, din Drive håller sig prydlig och dina automationer känns stabila igen.

Kontakta oss

Hör av dig, så diskuterar vi hur just din verksamhet kan dra nytta av alla fantastiska möjligheter som AI skapar.

Våra tjänster Om Node Nordic
×

Använd mall

Få direkt tillgång till denna n8n-arbetsflödes JSON-fil

Kopiera och importera JSON-arbetsflödet i ditt n8n-arbetsflöde