Akkurat den følelsen har vært litt for vanlig de siste månedene.
For å si det rett ut: GitHub har hatt en knall-tøff vinter og vår. Oppetiden falt under 90 prosent i 2025, og i april 2026 lå den under 85 prosent. Det er ikke akkurat tallene man drømmer om når man bygger sin egen tjeneste rundt en plattform.
For oss som lever i Laravel, Livewire og en god slump kaffe, har det vært en kavalkade av forstyrrelser. Et lite knippe høydepunkter fra logboka:
🧨 9. februar — to runder med nedetid samme dag, der github.com, API, Actions, Git-operasjoner og Copilot alle fikk hikke i nesten tre timer til sammen. Skyldig: en bitteliten konfigendring i en cache-mekanisme.
🧯 3. mars — på det verste feilet rundt 40 prosent av forespørslene mot github.com. Samme cache-greie som i februar, bare en ny vri.
🪤 23. april — en feil i Merge Queue gjorde at 658 repoer og 2 092 pull requests fikk endringer fra tidligere PR-er reversert. Altså: kode som var merget forsvant. Det er så marerittaktig som det høres ut.
🌊 27. april — Elasticsearch-klyngen druknet, sannsynligvis i en botnett-storm. Pull requests, issues og deler av prosjektgrensesnittet sluttet rett og slett å vise resultater.
🧹 28. april — kanskje den mest spektakulære: en manuelt utløst reparasjonsjobb for ett enkelt repo fjernet 1 789 756 838 PR-dokumenter fra søkeindeksen — omtrent halvparten. Ingen data tapt fra primærlageret, men de som søkte etter en gammel pull request den dagen, fikk en spennende dag på jobb.
Den ærligste forklaringen kommer fra GitHubs egen CTO, Vladimir Fedorov, og den er overraskende kjedelig — på en god måte. GitHub la i oktober 2025 en plan om å øke kapasiteten ti ganger. I februar 2026 innså de at de egentlig måtte planlegge for tretti ganger dagens skala. Hovedårsaken er en rask endring i hvordan programvare bygges: siden andre halvdel av desember 2025 har agentbaserte arbeidsflyter akselerert kraftig.
Med andre ord: vi mater plattformen med AI-agenter som lager repoer, åpner pull requests, kjører Actions og kaller API-er i et tempo som ingen menneskelig kommittéedrevet roadmap har klart å forutse. På stor skala bygger små ineffektiviteter seg opp: køer blir dypere, cache-bom blir database-last, indekser henger etter, retries forsterker trafikken, og én treg avhengighet drar med seg resten.
Det er ikke en unnskyldning. Men det er en gjenkjennelig historie for oss som har bygget systemer: alt fungerer fint helt til det plutselig ikke gjør det, og da er det aldri én ting som er ødelagt.
Midt oppe i alt dette dukket det opp et symbolsk øyeblikk. Mitchell Hashimoto — skaperen av Ghostty og medgründer av HashiCorp — annonserte at Ghostty-prosjektet flytter bort fra GitHub. Han er bruker nummer 1299, og har besøkt plattformen nesten daglig siden februar 2008. I over 18 år.
Det er ikke en sint utvandring. Hashimoto understreker at beslutningen ikke er direkte knyttet til den ene store nedetiden den 27. april. Den har modnet i flere måneder. Et lesbart speil av prosjektet vil fortsatt finnes på GitHub. Men poenget hans var likevel skarpt: når man fører dagbok over hvor mange dager nedetid faktisk hindrer arbeidet, og det blir et X på nesten hver eneste dato, da er det noe som har glidd ut av kontroll.
GitHub-sjefene leste det sannsynligvis samme morgen. Vlad Fedorov publiserte en lengre unnskyldning bare timer etter Hashimotos blogginnlegg. Innlegget endte med ordene «Vi er lei oss». Tone for ydmyk, men også et tegn på at presset begynner å sette seg.
For oss som bygger ting i det daglige, er ikke svaret panikk eller stor utvandring. Det er først og fremst noen små vaner som tåler å pusses opp:
Ha en plan B for CI. Hvis Actions ligger nede en hel ettermiddag, kan du fortsatt teste og bygge lokalt. Det er overraskende mange som har glemt det.
Ikke la merge-køen gjøre alt. Etter 23.-april-hendelsen er det kanskje verdt å se én ekstra gang på commit-historikken etter en stor squash-merge. Skader ikke.
Speil viktige repoer. En enkel daglig pull til en backupserver — eller til en annen plattform — koster lite, og gir en god natts søvn.
Kommuniser tidlig. Når Copilot eller Actions tøyser, har kundene dine sannsynligvis allerede sett det på X. Et kort "vi venter på GitHub" demper mye uro.
Skill mellom GitHub og Git. Git fungerer fortsatt fint på maskinen din selv om github.com blunker. SSH-baserte operasjoner har tålt seg overraskende godt gjennom de fleste hendelsene i vår.
Det er lett å bli sur, og litt sukkende kommentar er fortjent. Men jeg klarer ikke å la være å notere at GitHub faktisk gjør det de bør gjøre når man er i krise: de skriver detaljerte hendelsesrapporter, navngir komponenter, peker på det som var dumt, og legger ut oppdaterte tall når de finner ut at de tok feil først. De innrømte at det opprinnelige tallet for 23. april var litt høyt, og oppdaterte det offentlig. Det er en kultur det går an å respektere, selv når man er irritert.
Og bak alt dette ligger en sannhet som er litt morsom: GitHub sliter fordi vi har funnet på nye måter å bruke det på som ingen helt så komme. Det er ikke et tegn på en plattform i forfall. Det er et tegn på en plattform som forsøker å henge med på en bevegelse den selv har vært med å skape. AI-assistert utvikling er fortsatt så ny at vi ikke vet hva normalt belastningsmønster ser ut. GitHub får finne det ut på samme måte som resten av oss: ved å snuble litt på veien.
Skal jeg flytte alt vi har til en annen plattform? Nei. Skal jeg slappe av når det neste varselet kommer? Heller ikke. Men jeg har lagt til ett lite ritual: hver mandag morgen tar jeg en kjapp titt på githubstatus.com før jeg åpner mailen. Det er en finere måte å starte uka på enn å oppdage problemer fra en frustrert kollega på Slack.
Og hvis den blå feilmeldingen dukker opp igjen i ettermiddag — vel, det er kanskje på tide å brygge en ny kanne kaffe og se om naboen vil ta en prat. Koden går ingen steder. Den venter pent.