GitHub Copilot Automations: 13 Trin, 50 Min [2026]

GitHub har stille og roligt gjort Copilot til mere end et autocomplete-værktøj. Med funktionen Automations kan du nu sætte Copilots cloud-agent til at løse opgaver i baggrunden, uden at du selv skal skrive en ny prompt hver gang. Funktionen kom i public preview i GitHubs changelog den 10. september 2026, og den ændrer reelt hvordan et udviklerteam kan bruge AI til rutineopgaver som afhængighedstjek, oprydning i issues og ugentlige statusopdateringer.

I denne guide bygger vi en komplet automation fra bunden, trin for trin. Du får de nøjagtige klik, de trigger-typer der findes, en sammenligning med GitHub Actions, og en liste over de fejl der oftest får nybegyndere til at opgive opsætningen halvvejs. Sæt 50 minutter af, og du har en kørende automation ved slutningen af artiklen.

Automations er det seneste lag i GitHubs udvikling fra et kodelager til en platform fuld af agentiske funktioner. Copilot har allerede fået sin egen CLI, dev containers til at køre agenten lokalt, og mulighed for at tildele hele issues direkte til agenten. Automations lægger et fjerde lag ovenpå: tidsstyring. Det gør funktionen særligt relevant for teams, der allerede bruger Copilot til kodegennemgang eller custom instructions, og nu vil fjerne det sidste manuelle trin, nemlig at en person skal huske at starte opgaven hver gang.

Den bagvedliggende tendens er værd at bemærke, uanset om man selv arbejder med Copilot eller en anden assistent. Flere og flere AI-værktøjer flytter sig fra “svar på et spørgsmål, når jeg spørger” til “overvåg og handl, selv når jeg ikke er logget på”. Det giver reel tidsbesparelse, men det flytter også noget af ansvaret for kvalitetskontrol fra udvikleren, der skriver prompten i øjeblikket, til den, der har sat automationen op måneder forinden. Det er en af grundene til, at opsætningen fortjener mere omtanke end et hurtigt klik igennem standardindstillingerne.

Hvad er GitHub Copilot Automations?

En automation er en gemt Copilot cloud-agent-opgave, der kører automatisk, enten efter en tidsplan eller når noget specifikt sker i dit repository. I stedet for at skrive en prompt til Copilot hver gang du vil have tjekket afhængigheder eller ryddet op i gamle issues, definerer du opgaven én gang. Agenten genbruger den samme prompt, hver gang triggeren udløses, ifølge GitHubs egen dokumentation om automations.

Det afgørende skifte er, at opgaven ikke længere kræver en person ved tastaturet. Automationen ligger og venter i skyen, og den vågner, når tidspunktet eller hændelsen passer. Det gør funktionen relevant for alt fra sikkerhedsgennemgange til dokumentationsopdateringer, og det er netop derfor GitHub har valgt at placere den under en selvstændig fane kaldet Agents i stedet for at gemme den i de almindelige repository-indstillinger.

En automation består af fem dele, og det er værd at kende dem, før du åbner opsætningsskemaet for første gang, fordi de afgør hvor meget kontrol du reelt har over, hvad agenten laver i dit repository.

De Fem Byggesten I En Automation

Navn: bruges kun til at identificere automationen i listen, og har ingen funktionel betydning for selve kørslen.
Triggere: bestemmer hvornår automationen vågner, enten efter en tidsplan eller når en bestemt hændelse sker i repositoryet.
Prompt: det naturlige sprog, der beskriver opgaven. Den genbruges identisk ved hver kørsel, så den bør være skrevet så den holder over tid, ikke kun til én enkelt situation.
Model: den AI-model, der udfører selve fortolkningen og arbejdet. Valget påvirker både kvalitet og forbrug af AI-credits.
Værktøjer: den liste af handlinger agenten har lov til at udføre, for eksempel at læse filer, oprette pull requests, opdatere labels eller pushe ændringer.

Det sidste punkt, værktøjer, er det vigtigste fra et sikkerhedsperspektiv. Det afgør om agenten kun kan læse kode, eller om den også kan pushe ændringer, oprette pull requests og redigere issue-labels. Vi kommer tilbage til, hvordan du bør tænke dette punkt igennem, i afsnittet om sikkerhed og tilladelser.

Automations lever i den samme Copilot-app, som også huser den mere kendte chat-funktion og coding agent. Det betyder, at du kan tilgå og styre dine automations både fra github.com i browseren og fra GitHub-mobilappen, hvilket er praktisk hvis du vil tjekke status på en nattlig kørsel uden at skulle åbne en computer. GitHubs egen dokumentation for Copilot-appen beskriver automations som en del af det samlede sæt af måder, du kan interagere med cloud-agenten på, side om side med direkte chat og tildelte opgaver.

Forudsætninger: Dette Skal Du Have Klar

Før du går i gang, skal følgende være på plads. Automations er stadig i preview, så kravene kan ændre sig, men pr. oktober 2026 gælder dette:

Copilot-abonnement: Pro, Pro+, Max, Business eller Enterprise. Copilot Free understøtter ikke automations.
Repository-synlighed: Et privat eller internt repository. Automations er ikke tilgængelig på offentlige repositories ifølge GitHubs dokumentation.
Administratorrettigheder (kun Business/Enterprise): En organisationsadministrator skal have aktiveret cloud-agent-politikken, før almindelige medlemmer kan bruge funktionen.
Browser eller GitHub-app: Nyeste version af en opdateret browser (Chrome, Edge eller Firefox) eller GitHub mobilappen, da opsætningen foregår via fanen Agents på github.com.
Et aktivt repository med skriverettigheder: Du skal selv kunne skrive til repositoryet, da automations oprettes med din adgang som udgangspunkt.
GitHub CLI (valgfrit, men nyttigt til fejlfinding): gh version 2.80 eller nyere, hvis du vil tjekke din organisations Copilot-politik fra terminalen.

Har du ikke adgang til fanen Agents på dit repository, er det første du bør tjekke, om din plan og din organisations politik faktisk tillader cloud-agent-funktioner. Det dækker vi i fejlfindingsafsnittet senere.

Kravet om administratorgodkendelse på Business- og Enterprise-planer er ikke bare bureaukrati. Fordi en automation kan handle i et repository uden at et menneske trykker på noget i det konkrete øjeblik, giver det mening, at den samme type centrale kontrol, der allerede gælder for adgang til kildekode og hemmeligheder, også gælder for hvem der må sætte agenter til at handle automatisk. På mindre teams med Pro eller Pro+ er dette ikke et krav, men den samme tankegang er værd at anvende frivilligt: aftal internt, hvem der opretter automations, og hvor.

Automations vs. GitHub Actions vs. Copilot Coding Agent

Mange udviklere spørger med det samme: er det ikke bare GitHub Actions med et andet navn? Svaret er nej, og forskellen betyder noget for hvordan du vælger værktøj til en given opgave. GitHub Actions kører deterministiske trin defineret i YAML-filer. Du skriver præcis hvad der skal ske, i hvilken rækkefølge. Automations fungerer anderledes: du beskriver opgaven i almindeligt sprog, og Copilots cloud-agent fortolker selv hvordan opgaven skal løses inden for de værktøjer du har givet adgang til.

Copilot coding agent, som mange allerede kender fra at tildele issues til Copilot, er den tredje del af billedet. Det er en engangsopgave: du tildeler en specifik opgave, agenten arbejder på den, og den afleverer typisk en pull request. En automation er derimod en stående regel, der gentager den samme type opgave, hver gang triggeren rammer.

Egenskab	Copilot Automations	GitHub Actions	Copilot Coding Agent
Opgaven defineres som	Naturligt sprog (prompt)	YAML-workflow	Enkelt tildelt issue/opgave
Kører gentagne gange	Ja, efter schedule eller event	Ja, efter schedule eller event	Nej, kører én gang pr. tildeling
Fortolker opgaven selv	Ja, via AI-model	Nej, deterministisk	Ja, via AI-model
Typisk output	PR, issue-opdatering, labels	Build, test, deploy, artefakt	Pull request
Konfigureres via	Fanen Agents på github.com	.github/workflows/*.yml	Issue-tildeling eller prompt

I praksis supplerer de hinanden frem for at konkurrere. Du kan sagtens have en GitHub Action, der kører dine tests ved hver push, og en automation, der ugentligt beder Copilot om at gennemgå åbne issues og sætte relevante labels. Det ene erstatter ikke det andet.

En simpel tommelfingerregel: vælg GitHub Actions når opgaven har et fast, forudsigeligt svar, for eksempel at bygge, teste og udgive kode. Vælg en automation når opgaven kræver, at nogen “læser og vurderer” noget, for eksempel om en pull request ser komplet ud, om et issue er beskrevet godt nok, eller om en afhængighed reelt er sikker at opdatere. Vælg Copilot coding agent på en enkelt issue, når du har en konkret, afgrænset opgave, du vil have løst én gang, uden at det skal gentages efter et skema.

Trin 1-3: Aktiver Automations Og Åbn Agents-Fanen

Trin 1. Log ind på github.com og naviger til det repository, du vil automatisere. Husk at repositoryet skal være privat eller internt, ellers vil du ikke se automations-funktionen overhovedet.

Trin 2. Klik på fanen Agents i den øverste navigation på repositoryets forside. Fanen ligger sammen med de øvrige repository-faner som Code, Issues og Pull requests. Hvis fanen ikke findes, er det typisk fordi din plan ikke understøtter funktionen, eller fordi din organisations administrator endnu ikke har slået cloud-agent-politikken til.

Trin 3. Under Agents finder du en undermenu kaldet Automations. Klik dig ind, og du ser en liste over eksisterende automations (tom, hvis det er første gang). Hver linje i listen viser navn, trigger og status, så du hurtigt kan se hvad der kører, uden at åbne hver automation enkeltvis. I øverste højre hjørne ligger knappen, der starter hele processen.

Trin 4-6: Opret Din Første Automation

Trin 4. Klik på “New automation” i øverste højre hjørne. Du bliver nu præsenteret for et opsætningsskema med felter for navn, triggere, prompt, model og værktøjer, som beskrevet i GitHubs vejledning til oprettelse af automations.

Trin 5. Giv automationen et beskrivende navn. Det lyder banalt, men når du har fem eller ti automations kørende i samme organisation, er et navn som “Ugentligt afhængighedstjek – frontend” markant lettere at fejlfinde på end “Automation 3”.

Trin 6. Skriv selve prompten. Dette er hjertet af automationen, og den skal være specifik nok til at agenten ved, hvad “færdig” betyder. En vag prompt giver uforudsigelige resultater. Her er et eksempel på en solid prompt til et ugentligt afhængighedstjek:

Gennemgå package.json og package-lock.json i roden af repositoryet.
Find alle direkte afhængigheder, der har en nyere minor- eller patch-version
tilgængelig på npm. Ignorer major-versioner med breaking changes.
Opret én pull request med opdaterede versioner, en liste over hvad der er
ændret, og et link til changelog for hver pakke, hvis det findes.
Tilføj labelen "dependencies" til pull requesten. Hvis der ikke er nogen
opdateringer tilgængelige, skal du ikke oprette en pull request.

Bemærk den sidste linje. Uden den vil agenten i nogle tilfælde oprette tomme eller unødvendige pull requests, bare for at “levere noget”. At give agenten lov til at lade være er lige så vigtigt som at give den en opgave.

Trin 7-9: Vælg Trigger, Model Og Tilladelser

Trin 7. Vælg triggertype. Du kan vælge mellem en tidsplan (schedule) eller en repository-hændelse (event). Under schedule kan du vælge hourly, daily eller weekly, og for daily/weekly angiver du konkrete klokkeslæt og ugedage. Herunder ses de triggertyper, der er dokumenteret pr. oktober 2026:

Trigger	Beskrivelse	Bemærkning
Hourly	Kører hver time	God til overvågning af hurtigt skiftende data
Daily	Kører på valgte klokkeslæt hver dag	Mest brugt til rapporter og oprydning
Weekly	Kører på valgte ugedage og klokkeslæt	Typisk valg til afhængighedstjek
Issue opened	Kører når et nyt issue oprettes	God til automatisk triage og labeling
Pull request opened	Kører når en ny PR åbnes	Kan bruges til automatisk gennemgang
Pull request synchronize	Kører når nye commits pushes til en åben PR	Reagerer kun på ændringer i eksisterende PR, ikke generelle pushes
Issue/PR comment	Kører ved nye kommentarer, kan kræve bestemt tekst	Tilføjet i GitHubs changelog den 3. august 2026

Trin 8. Vælg model. Hvilke modeller du kan se i listen, afhænger af din Copilot-plan og eventuelle modelpolitikker sat af din organisation. Vælg en model, der matcher opgavens kompleksitet. Et simpelt afhængighedstjek behøver ikke den dyreste model i listen, mens en opgave der skal læse og omskrive dokumentation på tværs af mange filer, har mere gavn af en kraftigere model.

Trin 9. Vælg værktøjer og tilladelser. Dette er sikkerhedsgrænsen for automationen. Marker kun de værktøjer, agenten reelt behøver, for eksempel “opret pull request” og “opdater labels”, men lad være med at krydse “push direkte til main”, hvis opgaven kun handler om at forslå ændringer via en PR.

Trin 10-13: Test, Kør Og Godkend Automationen

Trin 10. Gem automationen. Den lægger sig nu i listen under Agents → Automations med status “aktiv” og en oversigt over næste planlagte kørsel. Du kan altid gå tilbage og redigere navn, trigger, prompt, model eller værktøjer, uden at skulle oprette en ny automation fra bunden.

Trin 11. Kør automationen manuelt én gang, før du læner dig tilbage og venter på tidsplanen. De fleste automations kan udløses on demand direkte fra listen, hvilket er den hurtigste måde at se, om prompten faktisk gør det, du forventer, uden at skulle vente til mandag morgen for at finde ud af, at noget er formuleret forkert.

Trin 12. Gennemgå resultatet. Hvis automationen opretter en pull request, vil output typisk se sådan ud:

Titel: Opdater 3 afhængigheder (patch/minor)

Beskrivelse:
- lodash: 4.17.21 -> 4.17.23 (patch, ingen breaking changes)
- axios: 1.9.0 -> 1.9.4 (patch, sikkerhedsrettelse)
- eslint: 9.14.0 -> 9.15.2 (minor, nye regler, ingen fejl i eksisterende config)

Labels: dependencies
Status: Afventer gennemgang

Trin 13. Juster tidsplan og prompt baseret på det første resultat, og godkend eller afvis den oprettede pull request som du ville med enhver anden PR. Automationen fjerner ikke behovet for menneskelig gennemgang, den fjerner behovet for at du selv starter opgaven.

Eksempel-Projekt: Ugentligt Afhængighedstjek Fra Start Til Slut

Lad os samle det til et komplet, virkende eksempel. Målet: hver mandag klokken 08:00 skal Copilot tjekke om der er opdateringer til projektets npm-afhængigheder, og hvis der er, skal den oprette én samlet pull request.

Navn: Ugentligt afhængighedstjek – main
Trigger: Weekly, mandag, 08:00
Model: Den model din organisation sætter som standard til rutineopgaver
Værktøjer: Læs filer, opret pull request, opdater labels
Prompt: Som vist i trin 6 ovenfor

Hvis du i stedet ville bygge den samme logik som en klassisk GitHub Action, ville den deterministiske udgave typisk se ud som nedenfor. Den kræver dog, at du selv vedligeholder scriptet, der afgør hvad der skal opdateres, og den kan ikke selv skrive en menneskeligt læsbar beskrivelse af ændringerne:

name: weekly-dependency-check
on:
  schedule:
    - cron: "0 8 * * 1"
jobs:
  check-updates:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: "22"
      - run: npm outdated --json > outdated.json || true
      - run: npx npm-check-updates -u
      - run: npm install
      - uses: peter-evans/create-pull-request@v6
        with:
          title: "Opdater afhængigheder"
          branch: deps/weekly-update

Forskellen bliver tydelig her. Actions-versionen kører præcis det script, du har skrevet, uanset hvor fornuftigt resultatet er. Automation-versionen fortolker opgaven, kan springe irrelevante opdateringer over, og kan skrive en begrundelse i almindeligt sprog. Til gengæld er Actions-versionen fuldstændig forudsigelig, og den kører uden at forbruge Copilot-ressourcer. Mange teams ender med at bruge begge dele til forskellige dele af samme proces.

Når automationen har kørt et par uger, bør du gennemgå de pull requests, den har oprettet, og justere prompten. Typiske justeringer er at tilføje undtagelser for bestemte pakker, bede om at større opdateringer splittes i separate PR’er, eller bede om, at automationen tagger en bestemt kollega som reviewer.

Et typisk forløb ser nogenlunde sådan ud i praksis. I første uge opretter automationen en pull request med tre små patch-opdateringer, og den bliver godkendt uden ændringer. I anden uge foreslår den en opdatering af en pakke, der faktisk indeholder en breaking change, selv om prompten bad den ignorere major-versioner, fordi pakkens eget versionsnummer ikke følger semantisk versionering korrekt. Det er her historikken og den manuelle gennemgang betaler sig: du retter prompten til specifikt at udelukke den pakke, og fra tredje uge kører automationen stabilt uden overraskelser. Den slags justering efter et par rigtige kørsler er normalt, ikke et tegn på at opsætningen var forkert fra start.

Tre Flere Brugsscenarier For Automations

Afhængighedstjek er det mest oplagte eksempel, men det er langt fra det eneste sted, automations giver værdi. Her er tre scenarier, flere teams allerede eksperimenterer med, siden funktionen kom i preview.

Automatisk Issue-Triage

Mange repositories drukner i issues uden labels, prioritet eller tydelig kategori. En automation med triggeren “issue opened” kan læse det nye issue, gætte på kategori baseret på indhold, og sætte relevante labels som “bug”, “feature-request” eller “needs-more-info”. Prompten kan se nogenlunde ud som nedenfor:

Læs det nyoprettede issue. Vurder om det beskriver en fejl, et
forslag til en ny funktion, eller et spørgsmål om brug.
Sæt præcis én label: "bug", "feature-request" eller "question".
Hvis issuet mangler nok information til at vurdere kategori,
sæt labelen "needs-more-info" og skriv en kort, venlig kommentar
der beder om flere detaljer. Rediger ikke titel eller beskrivelse.

Her er værktøjslisten afgørende igen. Automationen behøver kun adgang til at læse issuet og opdatere labels og kommentarer, ikke adgang til kode eller pull requests overhovedet.

Du kan kombinere triage-automationen med kommentar-triggeren, så en bruger kan skrive en kommentar som “/re-triage” på et issue, hvis den automatiske kategorisering var forkert, og få automationen til at køre igen med den nye information. Det giver et simpelt feedback-loop uden at skulle bygge en separat integration, og det er et godt eksempel på, hvordan de forskellige triggertyper kan spille sammen i stedet for kun at blive brugt én for sig.

Dokumentations-Frisktjek

En weekly- eller daily-automation kan sammenligne README-filer og setup-guider med den faktiske kode, og flagge hvis dokumentationen nævner kommandoer, filnavne eller versioner, der ikke længere findes i repositoryet. I stedet for at oprette en pull request med rettelser med det samme, kan prompten bede agenten om kun at oprette et issue med en liste over uoverensstemmelser, så et menneske beslutter, hvad der skal rettes, og hvordan.

Det tredje scenarie, flere sikkerhedsbevidste teams bruger, er en daily-automation der holder øje med nye sikkerhedsrådgivninger (advisories) for de pakker, projektet afhænger af, og opretter et issue med en kort opsummering og en vurdering af, om projektet reelt er påvirket. Det er ikke en erstatning for et dedikeret sårbarhedsscanningsværktøj, men det fungerer som et ekstra lag, der fanger ting, der ellers kunne blive overset i en travl uge.

Priser Og Plan-Understøttelse

Automations er ikke en selvstændig tilkøbsvare. Funktionen følger det Copilot-abonnement, du allerede har, og modelforbrug styres gennem GitHubs almindelige AI-credit-system, som trådte i kraft som den primære afregningsmodel fra 1. juni 2026. Her er de gældende planpriser, ifølge GitHubs plansammenligning:

Plan	Pris	Automations	Admin-krav
Copilot Free	0 $	Ikke understøttet	Nej
Copilot Pro	10 $/måned	Understøttet	Nej
Copilot Pro+	39 $/måned	Understøttet	Nej
Copilot Max	100 $/måned	Understøttet	Nej
Copilot Business	19 $/bruger/måned	Understøttet	Ja, cloud-agent-politik
Copilot Enterprise	39 $/bruger/måned	Understøttet	Ja, cloud-agent-politik

Bemærk at GitHub ikke offentliggør et fast antal kørsler eller en bestemt AI-credit-pris pr. automation-kørsel i den dokumentation, der er tilgængelig nu. Forbruget afhænger af den valgte model og opgavens omfang, ligesom når du selv skriver en prompt til Copilot Chat. Hold derfor øje med dit forbrug de første uger efter du sætter en automation op, i stedet for at antage at en planlagt opgave altid er gratis, bare fordi du ikke selv trykker på knappen hver gang.

Baggrunden for denne usikkerhed er, at GitHub skiftede hele Copilot til en forbrugsbaseret AI-credit-model den 1. juni 2026. Før den dato var mange handlinger inkluderet fladt i planprisen. Nu trækkes forbrug typisk fra en pulje af AI-credits, som varierer med planen, og en automation, der vælger en dyr model og kører hver time, kan derfor bruge markant mere af puljen end en automation, der kører ugentligt med en billigere model. Det betyder i praksis, at valg af model og triggerfrekvens ikke kun er et spørgsmål om kvalitet, men også om budget, på samme måde som når man vælger mellem forskellige AI-modeller i Copilot Chat.

Sikkerhed Og Tilladelser: Least Privilege I Praksis

Fordi en automation kan handle i dit repository uden at et menneske trykker “enter”, bør du behandle værktøjsvalget som en sikkerhedsgrænse, ikke en smagssag. En agent, der kun har lov til at læse filer og oprette en pull request, kan i værste fald foreslå noget dårligt. En agent, der har lov til at pushe direkte til main eller slette filer, kan gøre reel skade, hvis prompten er uklar eller modellen fejltolker opgaven.

Giv derfor kun adgang til de værktøjer, opgaven kræver. Skal automationen kun foreslå ændringer, så lad den oprette pull requests, men fjern retten til at pushe til beskyttede grene. Skal den kun rydde op i issue-labels, så giv den ikke adgang til at redigere kode overhovedet.

Branch-beskyttelse på main eller andre centrale grene er stadig din vigtigste sikkerhedsnet, uanset hvor godt du stiller værktøjerne op i automationens egen konfiguration. Hvis main allerede kræver godkendt review før merge, kan en automation i værste fald oprette en dårlig pull request, men den kan ikke selv lande den i produktionskoden. Kombinationen af begrænsede værktøjer i automationen og almindelig branch-beskyttelse på repository-niveau er den mest effektive måde at holde kontrol, uden at skulle genopfinde sikkerhedsmodellen for hver ny automation du opretter.

På organisationsniveau bør I overveje, hvem der må oprette automations, og i hvilke repositories de er tilladt. En administrator kan centralt styre cloud-agent-politikken for Business og Enterprise, og det bør bruges aktivt i stedet for at lade hver enkelt udvikler slå funktionen til efter eget forgodtbefindende.

For organisationer, der allerede er underlagt krav om dokumenteret adgangsstyring, for eksempel som del af NIS2-forberedelser eller interne sikkerhedspolitikker, giver det mening at behandle automations som endnu en type adgang til kildekoden, der skal med i den samme log og revision som øvrige integrationer og service-konti. En automation, der kan pushe til et repository, er i praksis en ny aktør med skriveadgang, selv om den optræder som en funktion i brugergrænsefladen snarere end som en separat bruger.

Hvis du vil tjekke din egen adgang og organisationens status fra terminalen, kan du starte med at bekræfte, at din GitHub CLI-session er gyldig, og at Copilot-udvidelsen er installeret:

gh auth status
gh extension list
gh api /repos/OWNER/REPO --jq '.visibility'

Den sidste kommando bekræfter, om repositoryet er privat, internt eller offentligt, hvilket er den hyppigste årsag til, at fanen Automations slet ikke vises for et givent repository.

5 Almindelige Fejl Ved Opsætning Af Automations

De fleste problemer med automations stammer ikke fra funktionen selv, men fra hvordan den sættes op første gang. Her er de fem fejl, der oftest dukker op, når teams begynder at bruge funktionen i praksis.

At skrive en for vag prompt. “Hold afhængigheder opdaterede” giver et uforudsigeligt resultat, fordi modellen selv skal gætte på, hvad “opdateret” betyder i din kontekst. Beskriv konkret hvad agenten skal lede efter, hvad den skal ignorere, og hvornår den slet ikke skal gøre noget.
At give for mange tilladelser fra start. Det er fristende at krydse alle værktøjer af, så man ikke skal tilbage og justere senere, men det betyder samtidig, at en fejltolket prompt kan få lov til at gøre mere skade end nødvendigt. Det modsatte er den rigtige vane: start minimalt, og udvid kun hvis opgaven reelt kræver det.
At forveksle “pull request synchronize” med en generel push-trigger. Den trigger reagerer kun på nye commits i en allerede åben pull request, ikke på enhver push til en vilkårlig branch. Hvis du forventer, at automationen reagerer på pushes til main, skal du vælge en anden triggertype eller løse det via GitHub Actions i stedet.
At prøve at bruge automations på et offentligt repository. Funktionen er pr. oktober 2026 begrænset til private og interne repositories. Mange nybegyndere leder forgæves efter fanen Agents i lang tid, uden at vide, at repositoryets synlighed er den egentlige årsag til, at den ikke dukker op.
At glemme at teste manuelt før man venter på tidsplanen. Hvis prompten er forkert formuleret, og automationen kun kører ugentligt, kan det tage uger at opdage fejlen, hvis du ikke kører den on demand først. En manuel testkørsel kvitterer med det samme, så du kan rette prompten, før den misser fire eller fem planlagte kørsler i træk.

Fejlfinding: 8 Problemer Og Deres Løsninger

Når noget ikke fungerer som forventet, er det næsten altid en af følgende otte situationer. Gennemgå dem i rækkefølge, før du begynder at omskrive hele prompten fra bunden.

Fanen Agents vises ikke: Tjek at din Copilot-plan understøtter automations, og at repositoryet ikke er offentligt. Et hurtigt tjek er at åbne et andet, privat repository og se om fanen dukker op der i stedet.
“New automation” er grået ud: Din organisations cloud-agent-politik er sandsynligvis ikke slået til. Kontakt en administrator, og bed specifikt om cloud-agent-politikken for Copilot, ikke blot generel Copilot-adgang.
Automationen kører, men gør ingenting: Prompten mangler sandsynligvis en klar definition af “færdig”. Tilføj konkrete kriterier for, hvornår agenten skal handle, og hvornår den skal lade være.
Automationen opretter tomme pull requests: Tilføj en explicit instruks om, at agenten ikke skal oprette en PR, hvis der ikke er relevante ændringer. Uden den linje “leverer” mange modeller noget, selv når der ikke er behov for det.
Trigger for kommentarer udløses ikke: Denne triggertype blev først tilføjet i august 2026 og kan kræve, at kommentaren indeholder en bestemt tekststreng. Tjek din konfiguration af betingelsen, og test med en kommentar der matcher teksten nøjagtigt.
Agenten kan ikke pushe ændringer: Det valgte værktøjssæt mangler sandsynligvis rettigheden til at skrive til repositoryet. Gå ind i automationens indstillinger og tilføj værktøjet, i stedet for at antage at adgang til at læse filer også giver skriveret.
Modelvalget mangler i listen: Modellen kan være deaktiveret af en organisationspolitik, eller din plan giver ikke adgang til den. Vælg en anden model fra listen, eller kontakt din administrator for at få den aktiveret.
Uventet højt forbrug af AI-credits: En hourly-trigger på en kompleks prompt kan hurtigt forbruge mere end forventet, fordi hver kørsel tæller som en selvstændig agent-session. Skift til daily eller weekly, og afgræns prompten til en mindre, mere specifik opgave.
Automationen reviewer forkert pull request: Hvis flere pull requests er åbne samtidig, kan en upræcis prompt gøre det uklart, hvilken PR agenten skal arbejde på. Tilføj en instruks om at bruge konteksten fra den hændelse, der udløste kørslen, i stedet for at lede bredt i hele repositoryet.

Avancerede Tips: Skaler Automations Over Flere Repositories

Når den første automation kører stabilt, er det næste naturlige skridt at gentage mønsteret i flere repositories. I stedet for at genopbygge hver automation manuelt fra bunden, kan du holde en fælles skabelon til prompten i et internt dokument, så teamet genbruger den samme struktur og det samme sprog, hver gang en ny automation oprettes.

Overvej også at lade automations arbejde i par. En weekly-automation, der tjekker afhængigheder, kan kombineres med en issue-comment-trigger, der lader en udvikler bede om en ekstra kørsel uden for skemaet, blot ved at skrive en bestemt kommentar i et issue. Det giver teamet kontrol, uden at man skal ind i opsætningen hver gang.

Følg desuden med i GitHubs changelog, da automations stadig er i preview og ændrer sig løbende. Kommentar-triggeren fra august 2026 er et godt eksempel på, hvordan nye triggertyper kan dukke op og åbne for helt nye brugsmønstre, uden at du selv skal gøre noget andet end at opdatere dine eksisterende automations.

Hvis du administrerer mange repositories, kan det også være værd at holde en kort liste over, hvilke automations der kører hvor, og hvilke værktøjer de har adgang til. Det er den samme logik som ved adgangsstyring generelt: det er let at oprette en ny automation, men det er let at glemme at rydde op i en gammel, når opgaven ikke længere er relevant.

Sæt desuden en fast kadence for at gennemgå automationernes kørselshistorik, for eksempel én gang i kvartalet. Se efter mønstre som automations der konsekvent ikke finder noget at gøre (måske er triggeren forkert valgt), eller automations der ofte bliver afvist af reviewer (måske er prompten ikke skarp nok). Begge mønstre er tegn på, at opsætningen bør justeres, i stedet for blot at lade automationen køre videre uændret.

Du kan læse GitHubs løbende opdateringer om funktionen i GitHubs officielle changelog, og den fulde oversigt over, hvordan Copilot-appen hænger sammen med automations, findes i dokumentationen for Copilot-appen.

Endelig er det værd at huske, at automations stadig er i public preview. Det betyder i praksis, at grænseflade, triggertyper og tilladelser kan ændre sig hurtigere end i en færdig, generelt tilgængelig funktion. Behandl derfor din første opsætning som et udgangspunkt, du forventer at justere i takt med at GitHub opdaterer funktionen, i stedet for en endelig konfiguration du sætter og glemmer.

Ofte Stillede Spørgsmål

Kan jeg bruge automations på et offentligt repository?
Nej, pr. oktober 2026 er funktionen begrænset til private og interne repositories ifølge GitHubs dokumentation. Vil du opnå noget lignende på et offentligt repository, er GitHub Actions eller Copilot coding agent på enkelte issues de nærmeste alternativer.

Koster det ekstra at bruge automations?
Der er ingen separat pris for selve funktionen. Forbruget trækkes fra dit eksisterende Copilot-abonnement og AI-credit-system, så det afhænger af hvilken model du vælger, og hvor ofte automationen kører. Hold derfor øje med forbruget i de første uger, i stedet for at antage at en planlagt opgave er gratis, bare fordi ingen trykker på en knap manuelt.

Kan Copilot Free bruge automations?
Nej. Funktionen kræver mindst Copilot Pro, eller en Business- eller Enterprise-plan med cloud-agent-politikken aktiveret af en administrator.

Hvad er forskellen mellem en automation og en GitHub Action?
En Action kører et deterministisk workflow defineret i YAML, hvor du selv skriver hvert trin. En automation beskrives i almindeligt sprog og fortolkes af Copilots cloud-agent, som selv afgør, hvordan opgaven løses inden for de tilladte værktøjer. De to kan sagtens bruges side om side i samme repository.

Kan en automation slette kode eller pushe direkte til main uden godkendelse?
Kun hvis du selv har givet den adgang til det værktøj. Som standard bør du begrænse automationen til at oprette pull requests, så en person stadig godkender ændringer, før de rammer main, uanset hvor meget du har tillid til prompten.

Hvor ofte kan en automation køre?
De dokumenterede tidsplaner er hourly, daily og weekly. Der er ikke støtte for brugerdefinerede cron-mønstre i den nuværende version, så har du brug for et andet interval, må du i stedet vælge den nærmeste tilgængelige tidsplan eller løse det via en GitHub Action.

Kan jeg bruge automations til at svare automatisk på kommentarer i issues?
Ja. Kommentar-triggeren, der blev tilføjet i august 2026, gør det muligt at udløse en automation, når der kommer en ny kommentar på et issue eller en pull request, eventuelt kun hvis kommentaren indeholder en bestemt tekst.

Hvordan ser jeg historikken for en automations tidligere kørsler?
Hver automation i listen under Agents → Automations viser sine seneste kørsler, inklusive hvilken trigger der udløste dem, og hvad resultatet blev, for eksempel en oprettet pull request eller en kommentar. Brug historikken aktivt, når du justerer en prompt, i stedet for kun at kigge på den seneste kørsel.