Dina GitHub-issues staplas av en anledning. Ingen har tid att läsa varje rapport, avgöra vad som är brådskande och skicka det till rätt person innan tråden blir brus.
Marknadsansvariga som hanterar produktfeedback, grundare som tar supportrollen och byråoperatörer som driver kundrepon känner igen sig. GitHub Slack-triage löser flaskhalsen genom att sortera issues snabbt och skicka korrekt formaterade notifieringar till Slack, så att du kan svara medan kontexten fortfarande är färsk.
Det här arbetsflödet fungerar som en AI-assistent för repo. Du får se vad det gör, vad du behöver och hur du anpassar det för dina egna repon.
Så fungerar den här automatiseringen
Hela n8n-flödet, från trigger till slutresultat:
n8n Workflow Template: GitHub + Slack: ärenden sorteras och skickas rätt
flowchart LR
subgraph sg0["Github Issue Hints Flow"]
direction LR
n0@{ icon: "mdi:brain", form: "rounded", label: "4o, 4o-mini, etc1", 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/webhook.dark.svg' width='40' height='40' /></div><br/>Webhook"]
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/webhook.dark.svg' width='40' height='40' /></div><br/>Respond to Webhook"]
n3@{ icon: "mdi:swap-vertical", form: "rounded", label: "CHANGE THESE!!!", pos: "b", h: 48 }
n4@{ icon: "mdi:robot", form: "rounded", label: "Github Issue Hints", pos: "b", h: 48 }
n5@{ icon: "mdi:cube-outline", form: "rounded", label: "Code Vector Read", pos: "b", h: 48 }
n6@{ icon: "mdi:cube-outline", form: "rounded", label: "Docs Vector Read", pos: "b", h: 48 }
n7@{ icon: "mdi:vector-polygon", form: "rounded", label: "Use Text Embedding 3 LARGE", pos: "b", h: 48 }
n8@{ icon: "mdi:swap-vertical", form: "rounded", label: "These too if you want", pos: "b", h: 48 }
n1 --> n3
n3 --> n8
n5 -.-> n4
n6 -.-> n4
n0 -.-> n4
n4 --> n2
n8 --> n4
n7 -.-> n6
n7 -.-> n5
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 n4 ai
class n0 aiModel
class n5,n6 ai
class n7 ai
class n1,n2 api
classDef customIcon fill:none,stroke:none
class n1,n2 customIcon
Problemet: issue-triage saktar ner allt
De flesta team har inte problemet “för många issues”. De har problemet osäkerhet. Är det här en riktig bugg eller användarfel? Är det brådskande eller bara högljutt? Hör det hemma hos engineering, support eller någon som äger dokumentationen? Så issues blir liggande. Under tiden fortsätter dubbletter att komma in, bidragsgivare blir ignorerade och interna Slack-pingar blir slumpmässiga (“kan någon titta på det här?”) i stället för åtgärdsbara. Det värsta är den mentala belastningen. Du läser samma tråd tre gånger eftersom du inte vill skicka den fel.
Det växer snabbt. Här är var det brister.
- Någon måste skanna varje nytt issue, och det är oftast den mest upptagna personen i teamet.
- Allvarlighetsgrad bedöms inkonsekvent, så en riktig blockerare kan ligga bredvid en liten UI-detalj i flera dagar.
- Dubblettrapporter slinker igenom eftersom ingen hinner söka igenom gamla trådar ordentligt.
- Slack-notiser är antingen för bullriga (alla mutar) eller för tysta (rätt person ser det aldrig).
Lösningen: AI-triage via webhook, sedan routa till Slack
Det här n8n-arbetsflödet gör varje inkommande GitHub issue-händelse till ett strukturerat, konsekvent triageresultat som du faktiskt kan använda. En enda webhook tar emot issue-payloaden, sedan injicerar n8n dina repo-inställningar (ägare, reponamn, routningsregler och valfria flaggor). Därifrån granskar en AI-agent issue-titel och brödtext och kan hämta extra kontext från din egen dokumentation eller kodbas via vektorsökningar (Pinecone är valfritt). Agenten returnerar en strukturerad svarspayload som du kan använda för att posta en kommentar, sätta etiketter eller skicka riktade Slack-notifieringar. Du får färre “läsa allt”-tillfällen och mer tydlighet i “här är nästa steg”.
Flödet startar när GitHub anropar din n8n-webhook. Sedan appliceras dina inställningar och val, AI-agenten klassificerar och utkastar ett svar med OpenAI och arbetsflödet returnerar triage-utdata så att du kan routa det till Slack (eller valfri larmkanal) utan manuell sortering.
Vad du får: automatisering kontra resultat
| Vad det här arbetsflödet automatiserar | Resultat du får |
|---|---|
|
|
Exempel: så här ser det ut
Säg att du får cirka 15 nya issues i veckan. Manuellt tar även en snabb genomgång och routning kanske 8 minuter per styck, plus ytterligare 5 minuter när du letar dubbletter eller klistrar in kontext i Slack. Det är ungefär 3 timmar i veckan bara för att sortera och notifiera. Med det här flödet lägger du ungefär 10 minuter i början på att sätta regler och kanaler, och sedan triageras varje issue automatiskt när det kommer in (oftast på under en minut), med Slack-notiser som redan är sammanfattade och rätt routade.
Det här behöver du
- n8n-instans (testa n8n Cloud gratis)
- Alternativ för self-hosting om du föredrar det (Hostinger fungerar bra)
- GitHub för att skicka issue-webhooks till n8n
- Slack för att ta emot routade notifieringar och sammanfattningar
- OpenAI API-nyckel (hämta den i OpenAI-dashboarden)
Kunskapsnivå: Medel. Du klistrar in webhook-URL:er i GitHub, kopplar Slack-/OpenAI-credentials och justerar några routningsfält.
Vill du inte sätta upp detta själv? Prata med en automatiseringsexpert (gratis 15-minuters konsultation).
Så fungerar det
GitHub skickar en issue-händelse till din webhook. Arbetsflödet börjar vid Incoming Webhook Trigger som tar emot issue-titel, brödtext, författare och metadata.
Dina repo-regler appliceras automatiskt. Två steg för att “sätta fält” (Assign Core Settings och Assign Extra Options) samlar sådant som annars brukar spridas över flera automatiseringar: repoOwner, repoName, vilka kanaler som ska notifieras och eventuell specialhantering som spamkontroller.
AI-agenten triagerar och utkastar svaret. GitHub Issue Advisor använder OpenAI Chat Model för att klassificera allvarlighetsgrad, sammanfatta issuen, föreslå etiketter eller nästa steg och valfritt slå upp kontext från din dokumentation och kod via vektorsökning.
Ett strukturerat resultat returneras för routning. Respond to Webhook skickar den slutliga triage-payloaden tillbaka till det som anropade webhooken, vilket gör det enkelt att koppla på ett Slack-notifieringsflöde, ett auto-kommentarsflöde eller båda.
Du kan enkelt ändra routningsreglerna så att de matchar din teamstruktur utifrån dina behov. Se hela implementationsguiden nedan för anpassningsalternativ.
Steg-för-steg-guide för implementering
Steg 1: konfigurera webhook-triggern
Konfigurera startpunkten som tar emot inkommande issue-payloads och startar arbetsflödet.
- Lägg till och öppna Incoming Webhook Trigger.
- Kopiera den genererade webhook-URL:en från Incoming Webhook Trigger och spara den för er avsändare (t.ex. GitHub eller er app).
- Bekräfta kopplingsflödet: Incoming Webhook Trigger → Assign Core Settings.
Steg 2: anslut AI-modeller och vektorbutiker
Konfigurera AI-komponenterna som används av rådgivningsagenten, inklusive språkmodellen och verktyg för vektorsök.
- Öppna OpenAI Chat Model och anslut den till GitHub Issue Advisor som ai_languageModel.
- Lägg till credentials i OpenAI Chat Model innan ni kör. Credential Required: Anslut era OpenAI-credentials.
- Öppna Docs Vector Lookup och Code Vector Lookup och säkerställ att båda är kopplade till GitHub Issue Advisor som ai_tool-inputs.
- Konfigurera OpenAI Embedding Large och säkerställ att den matar Docs Vector Lookup och Code Vector Lookup via anslutningen ai_embedding.
- Credential Required: Anslut era OpenAI-credentials på OpenAI Embedding Large. (Detta är en AI-subnod; modellens credentials ska läggas till i den överordnade konfigurationen i n8n om ni blir ombedda.)
- Credential Required: Anslut era Pinecone-credentials för både Docs Vector Lookup och Code Vector Lookup.
Steg 3: konfigurera datamappning med Set-noder
Förbered den inkommande payloaden för AI-agenten genom att lägga till och mappa fält i Set-noderna.
- Öppna Assign Core Settings och lägg till de grundfält som er agent behöver (t.ex. issue-titel, brödtext, repo).
- Öppna Assign Extra Options och lägg till eventuella valfria fält som används för svarsformatering eller routning.
- Verifiera flödet: Assign Core Settings → Assign Extra Options → GitHub Issue Advisor.
Steg 4: konfigurera AI-agenten och webhook-svaret
Koppla AI-agenten så att den producerar tips och returnerar dem till den ursprungliga webhook-anroparen.
- Öppna GitHub Issue Advisor och säkerställ att den använder OpenAI Chat Model som språkmodell.
- Bekräfta att Docs Vector Lookup och Code Vector Lookup är kopplade till GitHub Issue Advisor som verktyg.
- Öppna Return Webhook Reply och ställ in svarsformatet som er anropare förväntar sig (t.ex. JSON).
- Verifiera den slutliga output-vägen: GitHub Issue Advisor → Return Webhook Reply.
Steg 5: testa och aktivera ert arbetsflöde
Kör ett end-to-end-test för att bekräfta att webhooken, AI-svaret och det utgående svaret fungerar som förväntat.
- Klicka på Execute Workflow och skicka en test-payload till URL:en för Incoming Webhook Trigger.
- Bekräfta att Assign Core Settings och Assign Extra Options tar emot de förväntade fälten.
- Verifiera att GitHub Issue Advisor producerar ett svar med vektoruppslag och språkmodellen.
- Kontrollera att Return Webhook Reply returnerar svaret till anroparen.
- När allt är verifierat, växla arbetsflödet till Active för användning i produktion.
Vanliga fallgropar
- GitHub-credentials och webhook-hemligheter kan roteras. Om händelser slutar komma fram, kolla först GitHubs webhook-delivery-logs och bekräfta sedan att n8n-webhook-URL:en inte har ändrats.
- Om du förlitar dig på vektoruppslag (Pinecone) eller någon extern kunskapskälla kan svaren bli långsammare vid hög belastning. Öka timeouts och se till att nedströmsnoder inte utgår från att kontext alltid returneras.
- OpenAI-prompter som känns “helt okej” i test blir ofta slätstrukna i skala. Lägg in dina etiketteringsregler, ton och eskaleringspolicy i systemprompten tidigt, annars kommer du att behöva städa upp svar i efterhand.
Vanliga frågor
Cirka en timme om du redan har GitHub-, Slack- och OpenAI-åtkomst redo.
Nej. Du kommer mest att koppla konton och redigera några fält i inställningsnoderna.
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 OpenAI API-kostnader, som oftast är några cent per issue beroende på modell och kontextlängd.
Två alternativ: n8n Cloud (hanterad, 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änsade körningar men kräver grundläggande serveradministration.
Ja, och det bör du. Uppdatera reglerna i noderna “Assign Core Settings” och “Assign Extra Options” och justera sedan AI-agentens instruktioner så att den flaggar NSFW/egenreklam, sätter en allvarlighetsgrad och väljer rätt Slack-kanal för notifieringar. En vanlig setup är “kritiska buggar” till en on-call-kanal, “dokumentationsfrågor” till en community-kanal och “möjlig spam” till en privat granskningskanal.
Oftast når webhooken inte n8n. Kolla GitHubs webhook-delivery-logs efter ett icke-200-svar och bekräfta sedan att din n8n-webhook-URL är publik och oförändrad. Om du signerar webhook-payloads kan en felaktig hemlighet också orsaka fel. Mindre vanligt, men det händer: rate limiting eller payload-storleksproblem när du bifogar mycket kontext.
Många. På n8n Cloud beror det på din plan för månatliga körningar, och vid self-hosting beror det främst på serverstorlek och OpenAI-rate limits. I praktiken kör många små team hundratals issues per månad utan att tänka på det, särskilt om du håller prompterna tajta och bara använder vektoruppslag vid behov.
Ofta, ja, eftersom n8n är bättre när du vill ha kontroll över prompter, grenad logik och valfri self-hosting. Webhook-först-design som den här mappar också rent mot n8n, så du slipper kämpa med verktygsbegränsningar när du lägger till “en regel till”. Zapier eller Make kan fortfarande vara bra för ett enkelt flöde som “nytt issue → skicka Slack-meddelande”, och ärligt talat är det där de glänser. Om du är osäker, prata med en automatiseringsexpert och rimlighetskontrollera upplägget innan du investerar tid.
När det här väl rullar slutar din tracker kännas som en andra inkorg. Arbetsflödet sköter sortering och routning så att du kan fokusera på riktiga fixar och riktiga svar.
Kontakta oss
Hör av dig, så diskuterar vi hur just din verksamhet kan dra nytta av alla fantastiska möjligheter som AI skapar.