Gangguan pada Issues, Actions, dan operasi Git di GitHub

• Dilaporkan terjadi penurunan performa dan error pada layanan utama GitHub seperti Actions, Issues, dan operasi Git
• Cakupan dampak meluas ke Webhooks, Pull Requests, Packages, Pages, dan Codespaces
• GitHub menerapkan mitigation dan mengonfirmasi pemulihan bertahap, lalu seluruh layanan kembali normal
• Gangguan juga memengaruhi beberapa layanan seperti Dependabot dan Copilot, namun pada akhirnya kembali ke status operasional normal
• GitHub berencana merilis analisis akar penyebab (RCA) di kemudian hari dan menyampaikan terima kasih atas kesabaran dan kerja sama pengguna

---

Ringkasan gangguan

• GitHub mengumumkan sedang menyelidiki laporan penurunan performa pada Actions, Git Operations, dan Issues
  • Pada tahap awal teramati respons lambat dan permintaan gagal, serta pekerjaan Actions yang tertunda
  • Gangguan pertama kali dilaporkan pada 9 Februari 2026 pukul 19:01 UTC

Layanan yang terdampak

• Komponen yang terdampak meliputi Git Operations, Webhooks, Issues, Pull Requests, Actions, Packages, Pages, dan Codespaces
  • Setelah itu, masalah juga terkonfirmasi pada Dependabot dan Copilot
  • Masing-masing layanan ditandai dengan status “degraded performance”

Proses penanganan dan pemulihan

• GitHub melaporkan telah mengamati sinyal pemulihan setelah menerapkan mitigation
  • Pemulihan bertahap berlangsung setelah 19:29 UTC
  • Pada 19:54 UTC, banyak layanan telah pulih, tetapi sebagian masih dalam penyelidikan
• Pada 20:08 UTC dilaporkan bahwa “semua layanan beroperasi normal”
  • Pada 20:09 UTC status berubah menjadi Resolved

Status akhir dan tindak lanjut

• GitHub menyatakan semua layanan telah kembali ke status operasional normal
  • Actions, Codespaces, Git Operations, Issues, Packages, Pages, Pull Requests, dan Webhooks semuanya telah normal kembali
• Root Cause Analysis akan dibagikan setelah siap
• GitHub menyampaikan terima kasih atas kesabaran dan pengertian pengguna

Ringkasan

• Gangguan kali ini memengaruhi hampir seluruh workflow pengembangan inti GitHub
• RCA akan dipublikasikan setelah pemulihan selesai, dan perbaikan untuk mencegah gangguan serupa kemungkinan akan menyusul
• Fakta bahwa gangguan lain juga dilaporkan pada tanggal yang sama menyoroti pentingnya manajemen keandalan

[GN⁺]

Komentar Hacker News

• Karena gangguan parsial yang terus-menerus di GitHub, ada yang mempertimbangkan memindahkan seluruh perusahaan ke vendor lain
  Fitur-fitur yang dulu berjalan baik kini melambat, dan Actions juga tidak berjalan tepat waktu
  Copilot memang bagus, tetapi pada akhirnya jika git forge tidak berfungsi dengan baik, mereka tidak punya pilihan selain pergi

  • Sangat setuju. Dulu luar biasa, tetapi sekarang bahkan fungsi dasarnya pun tidak stabil
    Membuka diff PR sederhana saja bisa memakan waktu lebih dari 15 detik, dan UI berulang kali terasa seperti membeku
    Mengejutkan melihat penurunan performa yang tidak normal seperti ini dianggap biasa
  • Ucapan “menikmati Copilot” terdengar seperti lelucon
  • Ironisnya, Linus Torvalds merancang git untuk arsitektur tanpa sentralisasi
    Pada akhirnya, inti git adalah bahwa pipeline CI pun bisa dijalankan secara lokal
    Saya hanya memakai GH untuk sinkronisasi saja
  • Dulu GitHub sering merilis postmortem, tetapi belakangan hampir tidak ada
    Jika melihat tulisan lama, mereka sudah menabrak batas skalabilitas SQL DB
    Mirip dengan kasus ekspansi Postgres di OpenAI, tetapi GitHub tampaknya tidak menanganinya sebaik itu
  • Ada yang menilai ini sebagai masalah Microsoft, dengan nada bahwa “mengharapkan produk yang andal itu terlalu berlebihan”

• Gangguan GitHub yang sering justru menjadi kesempatan untuk memeriksa ketahanan pipeline deployment
  Kebanyakan tim sepenuhnya bergantung pada GitHub, sehingga deployment berhenti saat terjadi gangguan
  Karena itu, ada yang mencoba alternatif berikut

  1. Mencerminkan repo penting ke GitLab atau Gitea
  2. Caching dependensi untuk mencegah kegagalan build
  3. Menyiapkan runbook agar deployment manual tetap bisa dilakukan tanpa GitHub Actions
     Halaman status resmi selalu terlambat diperbarui, jadi sekarang dianggap hanya sebagai informasi yang “eventually consistent”

• Mungkin GitHub sedang terbebani oleh ledakan workflow pengembangan otomatis
  Commit di repo pribadi melonjak drastis, tetapi hampir tidak ada yang beralih ke paket berbayar

  • Masalah ini sebenarnya sudah dimulai setelah akuisisi Microsoft
    Ada yang menilai keputusan menggratiskan repo privat pada 2019 membuat peluang monetisasi hilang
  • Sebenarnya mereka sedang menjalani migrasi dari AWS ke Azure, sehingga gangguan sering terjadi
    Ditambah lagi, rasa tanggung jawab terhadap downtime dinilai kurang
  • Pada akhirnya mereka memang menabrak batas skalabilitas
  • Karena AI code generation, jumlah repo, commit, dan dataset meledak
  • Dirangkum dengan kalimat: “hidup karena boom AI Agent, mati karena runtuhnya AI Agent”

• Ada yang menyatakan GitLab adalah alternatifnya
  GitHub kini hanya fokus pada strategi berpusat pada AI, sementara platform itu sendiri menjadi prioritas kedua
  Tingkat adopsi Copilot juga rendah, dan perusahaan lebih banyak memakai Claude
  Jika Microsoft mengubah arah lagi, situasinya akan memburuk

  • Muncul pertanyaan apakah Copilot memakai model sendiri
  • Namun GitLab juga tidak sempurna
    Fitur dirilis dalam keadaan setengah jadi, dan performanya juga lambat
    Keunggulan model open-core pun kini makin memudar
  • GitLab juga bergerak ke arah AI
    Dari Dev → DevOps → DevSecOps → AI DevSecOps, tetapi
    di setiap tahap tingkat kematangannya kurang, dan upgrade lisensi menjadi keharusan yang merepotkan

• Struktur yang menggabungkan CI/CD dan code hosting ke dalam satu tempat dianggap sebagai masalah itu sendiri
  Bahkan jika semuanya berjalan sempurna, pada akhirnya vendor lock-in tetap tidak bisa dihindari
  Awalnya seharusnya cukup mengganti remote, tetapi sekarang semuanya terjerat oleh PR, wiki, dan lain-lain

  • Sebenarnya ini dianggap bukan kesalahan, melainkan strategi lock-in yang disengaja
  • Ada yang menilai penggunaan sistem CI independen seperti solusi open source forgejo sedikit lebih baik

• Kini gangguan GitHub terasa bukan sekadar masalah SaaS, melainkan gangguan setingkat cloud
  Karena itu banyak tim beralih ke GitLab/Gitea self-hosted

  • Ada yang berhasil memakai GitLab di dua startup
    Perusahaan besar menggunakan GitLab Enterprise on-premises karena alasan keamanan,
    sementara proyek pribadi dijalankan dengan Forgejo
    Git, issue, board, dan wiki semuanya berjalan baik, dan scoped label tersedia gratis
  • Self-hosted Gitea juga bagus. Asal pengelolaan backup dilakukan dengan baik
  • Self-hosting GitLab versi penuh dinilai sangat layak dibanding biayanya
  • Self-hosted GitLab jelas memuaskan

• Ada halaman yang memvisualisasikan rekam jejak banyak gangguan GitHub
  Bisa dilihat di mrshu.github.io/github-statuses

  • updog.ai/status/github juga memakai data berbasis Datadog
  • Namun pembaruannya tampak berhenti (terakhir 6 Februari)

• Ada juga komentar bercanda: “tim GitHub, santai saja, pelan-pelan juga tidak apa-apa”

• Ada yang ingin meninggalkan GitHub, tetapi tetap membutuhkan CI yang stabil dan container registry
  Jika ada solusi yang “pokoknya bekerja dengan baik”, mereka bersedia membayar

  • Merekomendasikan Lithus.eu yang menyediakan CI berbasis Forgejo + Firecracker VM
    Cocok untuk workload besar, tetapi biaya awalnya tinggi
  • GitLab CI sederhana tetapi kuat
    Pengelolaan izin registry sedikit rumit, tetapi integrasi keseluruhannya bagus
  • Ada yang mempertanyakan apakah repo memang seharusnya bertanggung jawab atas CI
    Mereka menilai harus kembali ke alat dengan tujuan tunggal seperti dalam filosofi Unix
  • Ada juga yang merekomendasikan nix-ci.com
  • CircleCI juga masih menjadi alternatif yang bekerja baik

• Menarik jika dibuat grafik korelasi antara tingkat adopsi AI dan frekuensi gangguan

  • Tentu saja, faktor-faktor lain juga kemungkinan ikut berperan