GitHubin laaja käyttökatko häiritsi kehittäjien työtä ympäri maailmaa

Aikajana: tutkimuksesta vaiheittaiseen palautumiseen

GitHub kertoi alkaneensa tutkia suorituskykyongelmia noin kello 13.40 UTC eli kello 16.40 Suomen aikaa 17. elokuuta. Ongelmat levisivät nopeasti palveluihin, joita kehittäjät käyttävät koodin hakemiseen, muutosten tarkistamiseen, automaation ajamiseen ja ohjelmistojen julkaisemiseen.

GitHub ilmoitti myöhemmin paikantaneensa ongelmiin liittyvän komponentin ja tehneensä korjaavia muutoksia. Kello 12.36 EDT julkaistussa päivityksessä yhtiö kertoi palvelun osoittavan selviä palautumisen merkkejä, vaikka toiminta ei ollut vielä täysin vakiintunut.

Palautuminen ei tapahtunut kaikkialla samanaikaisesti. GitHubin tilanneraportoinnin mukaan useat keskeiset palvelut palasivat toimintakuntoon, mutta Copilotissa jatkui joidenkin sovellusten tunnistautumisongelmia. Muiden häiriöraporttien mukaan koko tapahtuma päättyi noin kello 21.15 UTC, joten kokonaiskesto oli huomattavasti pidempi kuin pahimman palveluhäiriön ensimmäinen vaihe.

Kuinka vakava häiriö oli?

GitHubin ilmoittamat virhemäärät antavat selkeimmän kuvan vaikutuksista:

• Verkkokäyttö ja API-liikenne: virheitä noin 20 prosentissa pyynnöistä.
• Arkistolataukset ja repositorioiden raakasisältö: virheitä noin 50 prosentissa pyynnöistä.
• Kehittäjäpalvelut: Pull Requestit, Issues, Actions, Webhookit, Git-operaatiot ja Pages olivat eri vaiheissa hidastuneita tai poissa käytöstä.
• Tekoälyavusteinen ohjelmointi: GitHub Copilot kärsi häiriöstä, ja sen ongelmat jatkuivat vielä joidenkin ydintoimintojen palautumisen jälkeen.
• Yritysten identiteetinhallinta: raporttien mukaan ongelmia ilmeni SAML- ja OIDC-tunnistautumisessa, SCIM-provisioinnissa ja Team Syncissä. Tämä saattoi estää organisaatioita kirjauttamasta käyttäjiä sisään tai hallitsemasta käyttöoikeuksia luotettavasti.

20 prosentin API-virhemäärä ei siis tarkoita, että täsmälleen 20 prosenttia asiakkaista olisi ollut kokonaan offline-tilassa. Vastaavasti 50 prosentin latausvirhemäärä koskee kyseisiä latauspyyntöjä, ei kaikkea repositorioihin liittyvää liikennettä.

Miksi maanantaiaamu pahensi vaikutuksia?

Häiriö alkoi Yhdysvalloissa maanantaiaamuna eli monien ohjelmistotiimien työviikon alkaessa. Ajankohta on olennainen, koska koodin hakeminen, koodikatselmukset, jatkuva integraatio ja julkaisuautomaatio kuuluvat monilla tiimeillä päivän ensimmäisiin työvaiheisiin.

Koska Actions, Pull Requestit, API:t ja Webhookit olivat häiriintyneet, ongelmat saattoivat näkyä useassa toisiinsa liittyvässä vaiheessa yhtä aikaa. Tiimi ei välttämättä pystynyt hakemaan lähdekoodia, tarkistamaan muutoksia, käynnistämään automaattisia testejä tai toimittamaan julkaisuja.

Myös käyttökatkosta ilmoittaneiden palvelujen luvut vaihtelivat ajankohdan ja seurantatavan mukaan. Yhden raportin mukaan Downdetectorissa oli kello 8.12 Tyynenmeren aikaa kirjattu yli 10 000 ilmoitusta, kun taas toisessa palautumisraportissa huippulukemaksi kerrottiin lähes 3 000 ilmoitusta. Lukuja ei pidä tulkita tarkaksi käyttäjämääräksi: häiriöseurannat perustuvat käyttäjien lähettämiin ilmoituksiin, ja tuloksiin vaikuttavat muun muassa alue, ajankohta ja käytetty menetelmä.

Mitä GitHub teki – ja mitä se ei ole vielä kertonut?

GitHubin julkisista päivityksistä voidaan päätellä kolme asiaa:

1. Yhtiön insinöörit tutkivat useisiin palveluihin vaikuttaneita kohonneita virhemääriä ja suorituskykyongelmia.
2. GitHub tunnisti ongelmallisen komponentin ja toteutti korjaavia toimia.
3. Yhtiö jatkoi lievennystoimia sen jälkeen, kun tärkeimmät alustapalvelut alkoivat palautua. Työ koski muun muassa joissakin sovelluksissa jatkuneita Copilotin ajoittaisia tunnistautumisongelmia.

Saatavilla oleva näyttö ei kerro, mikä komponentti oli kyseessä tai millainen täsmällinen korjaus tehtiin. Se ei myöskään todista, että kapasiteettipaine olisi aiheuttanut juuri tämän käyttökatkon. Tekoälyavusteisen liikenteen kasvu ja infrastruktuurin rajoitteet kuuluvat GitHubin laajempaan luotettavuuskeskusteluun, mutta niitä ei pidä esittää 17. elokuuta koetun häiriön vahvistettuna juurisyynä ennen yhtiön lupaamaa jälkiselvitystä.

Osa GitHubin laajempaa vuoden 2026 luotettavuusongelmaa

Elokuun häiriö seurasi vaikeaa jaksoa. GitHubin heinäkuun saatavuusraportissa dokumentoitiin kahdeksan häiriötä. Yksi 8. heinäkuuta alkanut häiriö kesti yli seitsemän tuntia ja vaikutti verkkokäyttöliittymään, REST- ja GraphQL-rajapintoihin, Actionsiin, Packages-palveluun, Copilotiin ja Git-operaatioihin joissakin Enterprise Cloud -ympäristöissä.

GitHub on kuvannut taustalla olevan haasteen laajemmaksi infrastruktuuriongelmaksi. Yhtiön mukaan liikenne kasvaa nopeasti, ja kasvua vauhdittavat merkittävästi tekoälyavusteiset sekä itsenäisesti toimivat ohjelmistokehityksen työnkulut. Vastatoimiin kuuluvat kapasiteetin siirtäminen Azureen, palveluiden eriyttäminen ja yhteisten vikapisteiden vähentäminen.

Suunnitelmien mittakaava on huomattava. GitHubin alkuperäinen tavoite oli kasvattaa kapasiteettia kymmenkertaiseksi, mutta helmikuuhun 2026 mennessä yhtiö oli päätynyt siihen, että järjestelmät on suunniteltava jopa 30-kertaista aiempaan tasoon verrattavaa kapasiteettia varten. Muissa raporteissa on kuvattu Azureen liittyviä toimia ja lisäkapasiteetin hankkimista useasta pilvipalvelusta, myös AWS:stä. Nämä suunnitelmat eivät kuitenkaan yksin selitä elokuun häiriötä.

Konteksti tekee käyttökatkosta merkittävän yksittäistä huonoa työpäivää laajemmin. GitHub ei ole vain Git-repositorioiden säilytyspaikka, vaan samalla yhteistyöalusta, automaatioympäristö, identiteetinhallintajärjestelmä ja tekoälyavusteisen ohjelmoinnin palvelu. Kun yhteiset riippuvuudet pettävät, yksi häiriö voi keskeyttää repositorioiden käytön, koodikatselmukset, koontiversiot, julkaisut, Webhookit ja ohjelmointiavun yhtä aikaa.

Mitä organisaatioiden kannattaa tehdä?

Käyttökatko ei osoita, että kehittäjät olisivat joukoittain hylkäämässä GitHubia, eikä saatavilla oleva näyttö tue ennustetta lähestyvästä laajasta siirtymästä toiselle alustalle. Se kuitenkin muistuttaa, että tuotantojulkaisuissa GitHubiin nojaavien organisaatioiden kannattaa käydä läpi oletuksensa palvelun vikaantumisesta.

Käytännön varautumiskeinoja ovat esimerkiksi:

• repositorioiden varmuuskopiot tai peilaus,
• siirrettävissä olevat CI/CD-määritykset,
• dokumentoidut hätäjulkaisumenettelyt,
• vaihtoehtoiset toimintatavat tilanteisiin, joissa SSO, Webhookit tai isännöidyt runnerit eivät ole käytettävissä.

Toimet eivät poista alustariskiä, mutta voivat pienentää seuraavan häiriön vaikutusaluetta.

Lopullinen arvio 17. elokuuta tapahtuneesta riippuu GitHubin julkaisemasta jälkiselvityksestä. Tällä hetkellä perusteltu johtopäätös on rajatumpi: GitHub kärsi laajasta, ketjuuntuneesta palveluhäiriöstä, joka vaikutti erityisen voimakkaasti repositorioiden latauksiin ja toisiinsa kytkeytyviin kehittäjätyönkulkuihin. Palvelut palautuivat vaiheittain, mutta häiriön taustalla olevaa teknistä vikaa ei ole vielä kerrottu julkisuuteen.