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

GitHub + Gmail: varningar och rapporter om överbelastning

Rickard Andersson Partner, Nodenordic.se

Teamet levererar. Roadmapen rullar på. Och sedan, i det tysta, staplas de ”små” signalerna: commits sent på kvällen, merges på helgen, CI-fel, PR:er som väntar för länge. Du känner av det, men du kan inte bevisa det utan att lägga halva måndagen på att plocka fram siffror.

Den här uppsättningen för GitHub burnout alerts träffar Engineering Managers först, ärligt talat. Men CTO:er och tech leads hamnar ofta i samma detektivarbete när leveransen börjar svaja. Det här flödet förvandlar rå GitHub-aktivitet till en veckovis välmåenderapport och skickar sedan en Gmail-varning när risken sticker iväg.

Nedan ser du hur automatiseringen fungerar, vilka resultat du kan förvänta dig och hur du kör den på ett ansvarsfullt sätt (insikter på teamnivå, inte ”gotcha”-övervakning).

Så fungerar den här automatiseringen

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

n8n Workflow Template: GitHub + Gmail: varningar och rapporter om överbelastning

Varför det här spelar roll: utmattningssignaler döljer sig mitt framför ögonen

De flesta team har inte ett ”utmattningsproblem” förrän de har det. Det börjar med några sena kvällar för att nå en deadline, ett par helgfixar, en CI-pipeline som fallerar oftare och PR-granskningar som fortsätter att glida. Om du leder människor hamnar du i att gissa vad som är normalt och vad som är en varningssignal, eftersom GitHub-data är utspridd över commits, pull requests och workflow-körningar. Du kan ta fram det manuellt, absolut. Men att göra det varje vecka blir en återkommande skatt, och det är lätt att missa trenden tills någon går in i väggen eller kvaliteten sjunker.

Friktionen ökar över tid. Här är var det faller isär.

  • Veckovisa ”hur går det?”-kontroller blir 1–2 timmar av manuellt grävande i commits, PR:er och CI-historik.
  • Magkänsleledning tar över eftersom bevisen finns där, men inte sammanfattade på ett sätt du kan agera på.
  • Signaler misstolkas när du bara tittar på volym, inte mönster som arbete utanför kontorstid eller obalans i arbetsbelastning.
  • När risken är verklig dokumenteras den för sent, vilket gör uppföljning (och processförbättringar) svårare att motivera.

Det du bygger: veckovisa GitHub-välmåenderapporter + Gmail-varningar

Det här flödet körs enligt ett veckoschema och hämtar de aktivitetssignaler som ofta korrelerar med överbelastning. Det samlar in senaste commit-tider, pull request-aktivitet och CI/workflow-körningar från ditt GitHub-repo. Sedan omvandlar ett litet analyssteg råa händelser till tydliga ”arbetsmönster”-signaler, som arbete utanför kontorstid och helgaktivitet, plus samarbetsindikatorer som frekvens för PR-granskning och merges. Därefter producerar en AI-agent en professionell välmåendebedömning med skyddsräcken: evidensbaserad, teamfokuserad och utformad för att undvika personliga omdömen. Slutligen kan flödet skapa ett GitHub-ärende som loggar veckans rapport (bra för trenduppföljning) och skicka en Gmail-notis när risken passerar din tröskel.

Flödet startar med en schemalagd körning och en enkel konfiguration (repo-ägare, reponamn och återblicksperiod, vanligtvis 7 dagar). Därifrån hämtar det GitHub-data, tolkar mönster och genererar en veckorapport med en välmåendepoäng och rekommenderade åtgärder. Om poängen är oroande pingar Gmail rätt person så att det inte passerar obemärkt.

Det du bygger

Förväntade resultat

Säg att du gör en veckokontroll på tre ställen: commits, PR:er och workflow-körningar. Manuell kan du lägga cirka 30 minuter per område, och sedan ytterligare 30 minuter på att skriva en sammanfattning, alltså ungefär 2 timmar varje vecka. Med det här flödet kör den schemalagda triggen automatiskt, datainsamlingen sker i bakgrunden och du lägger bara cirka 5–10 minuter på att skumma den genererade rapporten. Om risken sticker iväg får du en Gmail-varning samma dag, istället för att upptäcka det under nästa veckas 1:1:or.

Innan du börjar

  • n8n-instans (prova n8n Cloud gratis)
  • Alternativ för self-hosting om du föredrar det (Hostinger funkar bra)
  • GitHub för repoaktivitet och API-åtkomst
  • Gmail för att skicka varningsmejl automatiskt
  • Groq API-nyckel (hämta den i Groq Console)

Svårighetsgrad: Medel. Du kopplar in autentisering och justerar några konfigfält som reponamn och varningsadress.

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

Steg för steg

Ett veckoschema sätter igång allt. n8n kör detta i den takt du väljer (veckovis som standard), så du är inte beroende av att någon kommer ihåg att ”göra hälsokollen”.

Repo-inställningar tillämpas. Ett enkelt konfigsteg sätter repo-ägare, reponamn, återblicksperiod (vanligtvis 7 dagar) och vart varningar ska mejlas via Gmail.

GitHub-aktivitet samlas in och normaliseras. Flödet hämtar workflow-körningar (CI-hälsa), senaste commits (inklusive tidpunkt) och pull requests (samarbete och genomströmning). Sedan omvandlar en kodbaserad analys det till signaler som arbete utanför kontorstid, helgaktivitet och fördelning av arbetsbelastning mellan bidragsgivare.

AI tar fram rapporten och åtgärder körs. AI-agenten genererar en strukturerad välmåenderapport för teamet med en hälsopoäng och rekommenderade nästa steg. Flödet loggar rapporten genom att skapa ett GitHub-ärende och kan skicka en Gmail-varning när poängen passerar din tröskel.

Du kan enkelt ändra varningströskeln och återblicksperioden utifrån dina behov. Se hela implementeringsguiden nedan för alternativ för anpassning.

Steg-för-steg-guide för implementering

Steg 1: Konfigurera triggern för schemalagd körning

Ställ in arbetsflödet att köras enligt ett veckoschema så att rapporten om repositoryts hälsa genereras automatiskt.

  1. Lägg till och öppna Scheduled Run Trigger.
  2. Ställ in intervallregeln att köra var 7:e dag (noden använder daysInterval inställt på 7).
  3. Bekräfta att exekveringsflödet startar i Scheduled Run Trigger och fortsätter till Set Repository Config.

Steg 2: Anslut GitHub-datakällor

Konfigurera repositoryidentifierare och hämtning av data via GitHub API i exakt den ordning som arbetsflödet använder.

  1. Öppna Set Repository Config och ställ in JSON Output till { "repoowner": "[YOUR_ID]", "reponame": "[YOUR_ID]", "period": 7, "emailreport": "[YOUR_EMAIL]" }.
  2. Öppna Retrieve Workflow Runs och ställ in URL till =https://api.github.com/repos/{{ $json.repoowner}}/{{ $json.reponame}}/actions/runs.
  3. I Retrieve Workflow Runs ställer ni in Query Parameters så att den innehåller created med värdet ={{ $now.minus({ days: $json.period || 7 }).toISO() }}..* och per_page med värdet 50.
  4. Inloggningsuppgifter krävs: Anslut era githubApi-inloggningsuppgifter i Retrieve Workflow Runs.
  5. Öppna Fetch Git Commits och ställ in URL till =https://api.github.com/repos/{{ $('Set Repository Config').first().json.repoowner }}/{{ $('Set Repository Config').first().json.reponame }}/commits.
  6. I Fetch Git Commits ställer ni in query-parametern created till ={{ $now.minus({ days: $json.period || 7 }).toISO() }}..*.
  7. Inloggningsuppgifter krävs: Anslut era githubApi-inloggningsuppgifter i Fetch Git Commits.
  8. Öppna Retrieve Pull Requests och ställ in Owner till =https://github.com/{{ $('Set Repository Config').first().json.repoowner }} och Repository till =https://github.com/{{ $('Set Repository Config').first().json.repoowner }}/{{ $('Set Repository Config').first().json.reponame }}.
  9. I Retrieve Pull Requests ställer ni in State till all och Direction till desc.
  10. Inloggningsuppgifter krävs: Anslut era githubApi-inloggningsuppgifter i Retrieve Pull Requests.

Exekveringsordningen är linjär: Scheduled Run TriggerSet Repository ConfigRetrieve Workflow RunsFetch Git CommitsRetrieve Pull RequestsEvaluate Dev ActivityWellness Analysis AgentNo-Op Placeholder.

⚠️ Vanlig fallgrop: Om ni glömmer att ersätta [YOUR_ID] och [YOUR_EMAIL] i Set Repository Config kommer alla efterföljande GitHub-anrop och e-postleverans att misslyckas.

Steg 3: Konfigurera processorn för utvecklingsaktivitet

Det här steget beräknar mönster för commits, PR:er och workflow-hälsa före AI-analysen.

  1. Öppna Evaluate Dev Activity och behåll JavaScript Code som angivet för att beräkna totaler, sena kvällar, helgarbete och felfrekvenser.
  2. Bekräfta att koden refererar till indata från Fetch Git Commits, Retrieve Pull Requests och Retrieve Workflow Runs.
  3. Verifiera att analysperioden härleds från Set Repository Config via period (standard 7 dagar).

Steg 4: Konfigurera AI-agenten för wellness-analys

Konfigurera AI-agenten, anslut Groq-modellen och säkerställ att agenten tar emot den beräknade JSON-analysen.

  1. Öppna Wellness Analysis Agent och behåll prompten i Text intakt för att bevara skyddsräcken och rapportstruktur.
  2. Bekräfta att prompten injicerar analysdata med {{ JSON.stringify( $('Evaluate Dev Activity').first().json )}}.
  3. Öppna Groq Chat Report Model och ställ in Model till openai/gpt-oss-120b.
  4. Inloggningsuppgifter krävs: Anslut era groqApi-inloggningsuppgifter i Groq Chat Report Model.
  5. Säkerställ att Groq Chat Report Model är ansluten till Wellness Analysis Agent som språkmodell.
  6. Observera att Create GitHub Issue och Gmail Report Dispatch är verktyg som är anslutna till Wellness Analysis Agent; lägg till inloggningsuppgifter via de överordnade verktygsanslutningarna i stället för att redigera undernoderna direkt.

Steg 5: Konfigurera utdataåtgärder

Definiera hur AI-rapporten skickas och loggas när kritiska larm upptäcks.

  1. Öppna Create GitHub Issue och behåll Title och Body mappade till AI-utdata med {{ /*n8n-auto-generated-fromAI-override*/ $fromAI('Title', ``, 'string') }} och {{ /*n8n-auto-generated-fromAI-override*/ $fromAI('Body', ``, 'string') }}.
  2. Säkerställ att Owner och Repository är inställda på {{ $('Set Repository Config').first().json.repoowner }} respektive {{ $('Set Repository Config').first().json.reponame }}.
  3. Inloggningsuppgifter krävs: Anslut era githubApi-inloggningsuppgifter via verktygsanslutningen i Wellness Analysis Agent för Create GitHub Issue.
  4. Öppna Gmail Report Dispatch och ställ in Send To till {{ $('Set Repository Config').first().json.emailreport }}.
  5. Behåll Subject som 📊 Team Health and Wellness Report och mappa Message till {{ /*n8n-auto-generated-fromAI-override*/ $fromAI('Message', ``, 'string') }}.
  6. Inloggningsuppgifter krävs: Anslut era gmailOAuth2-inloggningsuppgifter via verktygsanslutningen i Wellness Analysis Agent för Gmail Report Dispatch.
  7. Låt No-Op Placeholder vara kvar som en slutnod för felsökning eller framtida utbyggnad.

Tips: AI-instruktionerna anger att GitHub-issues och e-post endast används vid kritiska larm (Health Score < 90). Om ni vill avisera alltid, justera prompten i Wellness Analysis Agent.

Steg 6: Testa och aktivera ert arbetsflöde

Kör ett manuellt test för att bekräfta datahämtning, AI-analys och leverans av utdata innan ni aktiverar schemat.

  1. Klicka på Execute Workflow för att köra ett manuellt test från Scheduled Run Trigger.
  2. Verifiera att Retrieve Workflow Runs, Fetch Git Commits och Retrieve Pull Requests returnerar GitHub-data utan fel.
  3. Kontrollera utdata från Evaluate Dev Activity för beräknade totaler och frekvenser, och bekräfta sedan att Wellness Analysis Agent producerar en strukturerad HTML-rapport.
  4. Bekräfta att Create GitHub Issue och Gmail Report Dispatch endast körs när AI:n bedömer att det är ett kritiskt larm.
  5. När allt är validerat, slå på arbetsflödet till Active så att Scheduled Run Trigger körs veckovis i produktion.
🔒

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

Få den kompletta implementeringsguiden + nedladdningsbar mall

Felsökningstips

  • GitHub-inloggningar kan löpa ut eller kräva specifika behörigheter. Om det skapar fel, kontrollera först scopes för din personal access token (repo-åtkomst) och repo-synlighet.
  • Om du använder Wait-noder eller extern rendering varierar processtider. Öka väntetiden om nedströmsnoder fallerar på tomma svar.
  • Standardprompter i AI-noder är generiska. Lägg in din tonalitet tidigt, annars kommer du att redigera utdata i all evighet.

Snabba svar

Hur lång tid tar det att sätta upp den här automatiseringen för GitHub burnout alerts?

Cirka 30 minuter om du redan har din GitHub-token och Groq-nyckel.

Krävs det kodning för den här rapporteringen av utmattningsrisk?

Nej. Du kopplar främst konton och redigerar värden för repo-konfigurationen. Koden för mönsteranalysen ingår redan i flödet.

Är n8n gratis att använda för det här flödet för GitHub burnout alerts?

Ja. n8n har ett gratis self-hosted-alternativ och en gratis provperiod på n8n Cloud. Cloud-planer börjar på 20 $/månad för högre volym. Du behöver också räkna in kostnader för Groq API-användning, som varierar med rapportens storlek.

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

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 serverhantering.

Kan jag anpassa det här flödet för GitHub burnout alerts för andra use cases?

Ja, och det bör du troligen göra. De flesta team justerar värdena i ”Set Repository Config” (repo-ägare, reponamn, period) och anpassar prompten som används av Wellness Analysis Agent så att den matchar din ledarstil. Om du vill ha annan avisering byter du ut noden Gmail Report Dispatch mot Slack eller Teams och behåller resten av analysen intakt.

Varför misslyckas min GitHub-anslutning i det här flödet?

Oftast är det tokenen. Skapa en ny GitHub personal access token, säkerställ att den har rätt repo-behörigheter och uppdatera autentiseringen i n8n. Om repot ligger i en org kan SSO-inställningar blockera åtkomst tills du auktoriserar tokenen. Rate limiting kan också dyka upp om du frågar ett aktivt repo eller kör flödet för ofta, så veckovis körning hjälper.

Vilken volym kan det här flödet för GitHub burnout alerts hantera?

För ett enskilt repo med veckoschema fungerar det normalt bra på vilken n8n-plan som helst, eftersom det är en körning per vecka per repo.

Är den här automatiseringen för GitHub burnout alerts bättre än att använda Zapier eller Make?

Ofta, ja, eftersom det här inte är en enkel tvåstegszap. Du hämtar flera GitHub-endpoints, kör ett anpassat analyssteg och genererar en strukturerad rapport med en AI-agent, vilket är den typen av flersteglogik som blir klumpig (och dyr) i Zapier/Make. n8n ger dig också ett self-host-alternativ, så ”en veckorapport per repo” förblir förutsägbart när du skalar upp. Med det sagt: om du bara vill ha en enkel ”skicka ett mejl när commits sker” går Zapier snabbare. Prata med en automatiseringsexpert om du vill ha hjälp att välja.

Kör det veckovis, håll det objektivt, och du kommer att se överbelastning medan det fortfarande går att åtgärda. Flödet sköter bevakningen så att du kan fokusera på att leda teamet.

Kontakta oss

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

×

Använd mall

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

Launch login modal Launch register modal