- Setelah dua insiden terbaru, GitHub menempatkan ketersediaan sebagai prioritas utama dan sedang menata ulang infrastruktur serta arsitekturnya agar sesuai dengan lonjakan beban kerja pengembangan dan agentic development workflows
- Bahkan satu pull request pun terhubung luas ke repositori Git, Actions, pencarian, notifikasi, perizinan, webhooks, API, pekerjaan latar belakang, cache, hingga database, sehingga inefisiensi kecil dapat membesar menjadi penumpukan antrean dan penyebaran dependensi
- Dalam jangka pendek, fokusnya adalah mengurangi bottleneck dan beban database melalui migrasi backend untuk webhooks, perancangan ulang cache sesi pengguna, penyesuaian alur autentikasi dan otorisasi, serta perluasan komputasi berbasis Azure
- Dalam jangka panjang, GitHub meningkatkan ketahanan dan fleksibilitas melalui isolasi layanan inti, pengurangan single point of failure, pemindahan sebagian Ruby monolith ke Go, transisi ke public cloud, dan penyediaan jalur multi cloud
- Pada regresi merge queue 23 April dan kelebihan beban Elasticsearch 27 April, tidak ada kehilangan data, dan GitHub juga memperkuat transparansi dengan menambahkan metrik availability ke status page serta memperluas pengungkapan hingga insiden kecil
Latar belakang respons ketersediaan
- GitHub merangkum progres pekerjaannya dalam meningkatkan ketersediaan dan keandalan setelah dua insiden terbaru
- Sejak Oktober 2025, GitHub menjalankan rencana peningkatan kapasitas 10x, dan pada Februari 2026 menjadi jelas bahwa sistem perlu dirancang dengan asumsi skala 30 kali dari ukuran saat ini
- Perubahan cara pengembangan perangkat lunak menjadi latar belakang utamanya, dan sejak paruh kedua 2025, agentic development workflows melaju sangat cepat
- Pembuatan repositori, aktivitas pull request, penggunaan API, otomatisasi, dan beban kerja repositori besar semuanya meningkat dengan cepat
Beban struktural yang terlihat dalam proses penskalaan
- Satu pull request dapat menyentuh repositori Git, mergeability checks, branch protection, GitHub Actions, search, notifications, permissions, webhooks, API, background jobs, caches, hingga databases sekaligus
- Pada skala besar, inefisiensi kecil pun dapat menumpuk menjadi penumpukan antrean, perpindahan beban ke database akibat cache miss, keterlambatan indeks, amplifikasi trafik retry, dan dampak lintas produk dari dependensi yang lambat
- Prioritasnya disusun sebagai ketersediaan lebih dulu, lalu kapasitas, kemudian fitur baru
- GitHub menjalankan pengurangan pekerjaan yang tidak perlu, peningkatan cache, isolasi layanan inti, penghapusan single point of failure, dan pemindahan jalur sensitif performa ke sistem khusus secara paralel
- Tantangan utamanya adalah mengurangi keterikatan tersembunyi, membatasi blast radius, dan memastikan graceful degradation agar tekanan pada satu subsistem tidak menjatuhkan keseluruhan sistem
Peningkatan yang sedang berlangsung saat ini
- Dalam jangka pendek, GitHub fokus mengatasi bottleneck yang muncul lebih cepat dari perkiraan
- GitHub telah memindahkan webhooks ke backend lain di luar MySQL, merancang ulang cache sesi pengguna, dan menyesuaikan kembali alur autentikasi serta otorisasi untuk secara signifikan mengurangi beban database
- Dengan memanfaatkan migrasi ke Azure, GitHub juga memperoleh lebih banyak sumber daya komputasi
- Setelah itu, fokus beralih ke isolasi layanan inti seperti git dan GitHub Actions serta pengurangan single point of failure
- GitHub menganalisis dependensi dan lapisan trafik secara rinci untuk menentukan apa yang perlu dipisahkan, lalu menangani risiko berdasarkan prioritas agar berbagai serangan berdampak seminimal mungkin pada trafik normal
- Pekerjaan untuk memindahkan sebagian kode yang sensitif terhadap performa atau skala dari Ruby monolith ke Go juga dipercepat
- Di tengah proses pemindahan dari data center internal berskala kecil ke public cloud, GitHub juga mulai mendorong jalur multi cloud untuk jangka lebih panjang
- Langkah jangka panjang ini diperlukan untuk mendapatkan ketahanan, latensi rendah, dan fleksibilitas yang akan dibutuhkan ke depan
Penanganan repositori besar dan merge queue
- Dibanding sekadar pertumbuhan jumlah repositori, GitHub menilai peningkatan monorepo besar sebagai tantangan penskalaan yang lebih sulit
- Dalam tiga bulan terakhir, investasi untuk merespons tren ini telah ditingkatkan secara besar baik pada sistem git maupun pengalaman pull request
- Pekerjaan terkait desain API baru untuk efisiensi dan skalabilitas yang lebih tinggi juga sedang berjalan dan akan dipublikasikan melalui posting blog terpisah
- GitHub juga berinvestasi pada optimalisasi pekerjaan merge queue karena hal ini penting bagi repositori yang menerima ribuan pull request per hari
Insiden terbaru 1: masalah merge queue pada 23 April
- Pada 23 April, terjadi regresi perilaku merge queue pada pull request
- Pada merge queue yang menggunakan metode squash merge, jika merge group berisi lebih dari satu pull request, akan dibuat merge commit yang salah
- Dalam kasus yang terdampak, merge berikutnya dapat berujung pada kondisi di mana perubahan dari pull request yang telah digabung lebih dulu dan commit yang sudah ada justru tidak sengaja dibatalkan
- Selama periode terdampak, 658 repositori dan 2.092 pull request terkena dampak
- Angka awal dibagikan secara konservatif, sehingga jumlah yang pertama diumumkan sedikit lebih tinggi dari ini
- Pull request yang digabung di luar merge queue tidak terdampak, dan merge queue group yang menggunakan metode merge atau rebase juga tidak terdampak
- Tidak ada kehilangan data. Semua commit tetap tersimpan di Git
- Namun, status branch default pada repositori yang terdampak menjadi salah, dan tidak semua repositori bisa dipulihkan secara otomatis dengan aman
- incident root cause analysis: detail tambahan dapat dilihat di sana
- Insiden ini mengungkap beberapa kegagalan proses, dan GitHub sedang mengubah proses tersebut agar masalah serupa tidak terulang
Insiden terbaru 2: masalah terkait pencarian pada 27 April
- Pada 27 April, terjadi gangguan pada subsistem Elasticsearch yang menangani berbagai pengalaman berbasis pencarian
- Cakupan dampaknya mencakup sebagian UI berbasis pencarian untuk pull requests, issues, dan projects
- Analisis akar penyebab masih dalam tahap penyelesaian dan akan segera dipublikasikan
- Berdasarkan temuan saat ini, cluster berada dalam kondisi kelebihan beban, sehingga gagal mengembalikan hasil pencarian
- Sebagai penyebab kelebihan beban, kemungkinan serangan botnet juga masih terbuka, tetapi analisis akar penyebab belum selesai
- Tidak ada kehilangan data, dan operasi Git serta API tidak terdampak
- Namun, sebagian UI yang bergantung pada pencarian sama sekali tidak dapat menampilkan hasil, sehingga menimbulkan kebingungan besar
- Sistem ini adalah area yang isolasi penuhnya untuk menghapus single point of failure belum selesai, dan sebelumnya risiko di area lain memiliki prioritas lebih tinggi
- GitHub sedang menerapkan analisis dependensi dengan pendekatan yang sama serta pengurangan blast radius untuk menurunkan kemungkinan dan dampak kegagalan seperti ini
Memperkuat transparansi insiden
- Saat insiden terjadi, menjadi jelas bahwa pelanggan menginginkan transparansi yang lebih besar
- GitHub baru-baru ini memperbarui GitHub status page agar mencakup angka availability
- GitHub juga memutuskan untuk mencantumkan bukan hanya insiden besar tetapi juga insiden kecil di status page, dengan tujuan agar pengguna tidak perlu menebak apakah masalah ada di pihak mereka atau di pihak GitHub
- Cara klasifikasi insiden juga terus diperbaiki agar skala dan cakupannya lebih mudah dipahami
- GitHub juga sedang meningkatkan cara pelanggan membagikan sinyal dan melaporkan masalah selama insiden berlangsung
Janji ke depan
- GitHub berkomitmen pada peningkatan ketersediaan, perluasan ketahanan, penskalaan yang sesuai dengan skala pengembangan perangkat lunak masa depan, dan komunikasi yang lebih transparan
- Jumlah repositori yang terdampak dalam insiden 23 April diperbarui per 28 April 2026
1 komentar
Opini Hacker News
GitHub hanya dalam tahun ini saja sudah mengalami puluhan kali gangguan, dan dibanding tahun lalu, ketersediaan serta keandalannya terlihat jelas memburuk
Sampai separah ini rasanya dashboard dan heatmap pun pantas dibuat, dan di tempat seperti HN atau Reddit ketidakstabilan GitHub sudah sampai level bisa jadi meme
Meski begitu, mengatakan prioritasnya adalah "availability, capacity, new features" terasa terlalu longgar dalam membaca kenyataan
Saat ini prioritas 1, 2, 3 semuanya seharusnya availability, dan minimal 6 bulan jangan bahas hal lain, perbaiki itu saja
Enam bulan lalu katanya migrasi ke Azure adalah prioritas utama sehingga pengembangan fitur ditunda, tapi sekarang malah bilang availability lagi yang paling utama, jadi terasa tidak nyambung
Waktu itu mereka bilang batas kapasitas data center Virginia karena permintaan AI dan Copilot itu bersifat "existential", jadi makin aneh melihat mereka masih limbung karena masalah yang sama
Katanya pengembangan fitur ditunda, tapi tiap minggu tetap keluar fitur baru dan perubahan UI, dan belum lama ini tampilan issue tunggal juga diubah
Sulit dipercaya perusahaan dengan sumber daya sebesar Microsoft bisa terus tersandung di tempat yang sama, dan strategi membeli layanan developer populer lalu memindahkan semuanya ke platform yang sama juga terlihat mengkhawatirkan
Di organisasi engineering besar, prioritas tidak selalu saling eksklusif, dan tim yang tidak bisa berkontribusi langsung ke prioritas inti bisa saja tetap mengerjakan fitur lain
https://news.ycombinator.com/item?id=47912521
Hardware khusus lebih bisa diprediksi daripada cloud, dan keputusan seperti "jangan pindah ke Azure, beli beberapa rack lagi saja" mungkin memang bukan sesuatu yang bisa diputuskan manajemen GitHub sendiri
GitHub bukan situs yang perlu didesain ulang tiap 5 menit, dan kadang terlihat seperti para manajer mendorong fitur demi fitur baru hanya untuk membuktikan alasan keberadaan mereka
Akibatnya, makin banyak yang dirusak justru makin kontraproduktif untuk menarik pengguna
Search juga kena nerf besar, dan seperti Google Search atau YouTube, saya tidak paham kenapa semua orang terus merusak search yang tadinya baik-baik saja
Selain itu Microsoft punya Azure DevOps yang nyaris terasa ditelantarkan dan juga GitHub, dan saya tidak suka keduanya, terutama sistem tiketnya
Saya sudah lelah karena tiap proyek Jira pengaturannya beda-beda, tapi sekarang sampai muncul ucapan, "malah jadi kangen Jira"
Tulisan itu terasa sulit dibaca dengan muka serius
Grafik tanpa label yang cuma menampilkan angka besar, prioritas yang tidak cocok dengan pengalaman nyata, dan sikap yang tidak benar-benar mengakui uptime mengerikan selama 12 bulan terakhir terasa sangat mengganggu
Memang label sumbu kiri bawah tidak ada, tapi inti bahwa laju pertumbuhan sangat cepat dari 2023→2024→2025→2026 tetap tersampaikan
Sekitar awal atau akhir 2026, grafik itu terbaca seperti menunjukkan pertumbuhan yang lebih besar daripada gabungan tiga tahun sebelumnya, dan tanpa tahu angka sumbunya pun tren kasarnya masih bisa dilihat
Memang perlu asumsi bahwa itu grafik linear, tapi dalam konteks ini asumsi seperti itu tidak terasa berlebihan
Jika perusahaan mengalami pertumbuhan jauh di atas rencana, masalah kapasitas memang nyaris tak terelakkan, dan sekarang tampaknya mereka butuh efisiensi backend, bukan sekadar menambah hardware
Target yang mereka tulis juga sebagian besar memang mengarah ke sana
https://x.com/kdaigle/status/2040164759836778878
Saya tidak tahu apakah orang tidak percaya bahwa pertumbuhannya sekarang eksponensial, atau justru menganggap pertumbuhan 10x per tahun itu bukan hal sulit
https://damrnelson.github.io/github-historical-uptime/
Kalimat "kami telah memulai jalur multi-cloud" terdengar seperti pengakuan tidak langsung bahwa Microsoft merasa Azure saja tidak bisa memberikan tingkat keandalan yang mereka inginkan
Mungkin bisa membantu menjaga retensi
Awalnya tujuannya operasi dengan sangat sedikit campur tangan manusia, tapi sekarang katanya prosedur sehari-hari justru seperti orang menempelkan kabel serial ke rack atau VM lalu mengutak-atik langsung
Saya tidak bisa menemukan tautannya sekarang
Pembaca paling aktif banyak di hari Senin–Kamis pukul 9–11 pagi waktu Pacific, dan akhir pekan memang kompetisinya lebih sedikit tapi keterlibatannya juga rendah
CTO GitHub juga ada di dewan Codepath.org, dan kalau deskripsinya berbunyi semacam "menciptakan generasi pertama engineer, CTO, dan pendiri yang AI-native", rasanya jadi cukup kebayang di mana masalahnya
Secara pengalaman, stabilitas GitHub memang terasa jauh lebih buruk, dan belakangan bahkan data yang ditampilkan di web pun sulit dipercaya
Sejak kemarin saya dan beberapa rekan melihat daftar PR tampil tidak lengkap di berbagai repositori
Misalnya di https://github.com/gap-system/gap/pulls, tab menampilkan "Pull requests 78" tetapi di tampilan daftar hanya terlihat "35 open"
Angka 78 terbukti benar juga lewat
gh pr list, tetapi https://www.githubstatus.com tetap menampilkan "all systems operational"Lewat CLI daftarnya muncul, tetapi lewat jalur web yang melewati search semuanya menghilang
Tim support memang mengakui isu ini, tetapi setelah itu sunyi, dan di halaman status juga tidak ada apa-apa selain isu tanggal 27 yang mungkin terkait
Di beberapa repo kelihatannya sempat pulih di tengah jalan, tetapi di banyak org dan repo lain masalahnya masih terus bisa direproduksi
https://github.com/orgs/community/discussions/193388
PR yang hilang itu baru bisa saya temukan dengan susah payah lewat halaman branch
Mungkin bukan bug murni, melainkan keputusan produk yang sangat buruk untuk mengurangi beban infrastruktur
Tetap saja, publikasi data repo/issues/commits baru selama beberapa tahun terakhir cukup menarik
Seperti yang sudah banyak diduga dari luar, itu mengonfirmasi bahwa agen-agen memberi beban tambahan yang besar dan mendadak ke GitHub
Mereka pada dasarnya mengalami pertumbuhan eksponensial ala startup sambil tetap harus melayani basis pengguna yang sudah raksasa, jadi wajar menjadi sasaran empuk, dan organisasinya juga tampaknya tidak akan mudah bergerak cepat
Sebaliknya, mereka juga punya talenta, infrastruktur, dan dana yang jauh lebih besar daripada startup
Yang ada hanya satu grafik tanpa label dan angka puncak saat ini
Entah apa yang dilakukan pada grafik-grafik itu, tapi hasilnya nyaris seperti lukisan impresi seorang seniman
Melihat grafik commit, tidak jelas kenapa muncul langkah besar lalu menurun landai, kenapa langkah itu tidak terjadi di titik yang konsisten, atau kenapa lompatan yang lebih besar kadang justru punya kemiringan yang lebih kecil
Grafik lain juga bergerak dengan bentuk yang sama sekali berbeda, jadi makin aneh
Fungsinya bukan menunjukkan data nyata atau makna data, melainkan sekadar menyampaikan bahwa "sesuatu sedang naik"
Saya rasa federated forges memang masa depan
Repositori di-host masing-masing pada sovereign infra, lalu di atasnya ditambahkan global ID serta metadata terfederasi untuk issue·PR dan sebagainya
Indeks global seperti ini juga mudah dijalankan, jadi availability tidak perlu menjadi kekhawatiran besar, dan kami juga sedang bekerja ke arah itu
Pada akhirnya kalau tetap memakai hosting pihak ketiga, kemungkinan besar 1–3 penyedia besar akan muncul lagi
Dan walau self-hosting untuk menghindari masalah availability, kalau dependensi Anda tetap bergantung pada layanan besar seperti GitHub, gangguan di sana juga tetap tidak terhindarkan
Jadi solusi realistisnya, seperti sekarang, adalah mem-proxy atau me-mirror semua yang dipakai
Simpan repo yang sama di GitHub, Codeberg, dan self-host, lalu jaga konsistensi branch utamanya
Setelah itu Anda bisa memperbarui dari mana saja, dan tinggal pasang tautan yang jelas di README
Kalau forge lain yang menyediakan API atau webhook yang layak bisa dihubungkan untuk memberi kenyamanan yang sama, saya ingin semuanya pindah ke self-host
Sisi agen tentu juga perlu membuka interfacenya, tetapi kalau strukturnya plugin, ketergantungan pada GitHub mungkin bisa dilepas dan sisanya ditangani dengan MCP atau skills
Saya tidak masalah self-hosting runner besar, jadi belakangan saya pindah ke Codeberg, dan untuk pekerjaan cron kecil saya memakai runner yang disediakan Codeberg
Di sana bahkan ada lazy runner untuk kegunaan seperti ini
Yang sedang mereka lakukan sekarang terlihat seperti ini
Subsidi token sudah menyedot cukup banyak data pelatihan dan bisnis para pecandu agentic kini sudah cukup besar untuk memutar flywheel, jadi mereka tampaknya akan menghentikannya dan membereskan produk yang sengaja merugi
https://news.ycombinator.com/item?id=47923357