Gangguan Issues dan Webhooks – Terselesaikan

 (githubstatus.com)
1 poin oleh GN⁺ 2 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • GitHub menyelidiki penurunan performa pada Issues dan Webhooks, lalu mengubah status insiden menjadi terselesaikan pada 4 Mei 2026 pukul 16:40 UTC
  • Insiden ini berdampak pada Git Operations, Webhooks, Issues, Pull Requests, Actions, Packages, Pages, dan Codespaces
  • Pada 15:45 UTC investigasi penurunan performa Issues dan Webhooks dimulai, lalu pada 15:48 UTC cakupannya diperluas ke investigasi peningkatan latensi dan timeout di beberapa layanan GitHub
  • Mulai 16:25 UTC, Git Operations, Actions, Packages, Pages, Pull Requests, Issues, Codespaces, dan Webhooks secara bertahap pulih atau terdampak lebih ringan
  • GitHub menyatakan latensi di seluruh layanan telah kembali normal, dan akan terus melakukan pencegahan agar tidak terulang serta analisis akar penyebab untuk dibagikan saat sudah siap

Ringkasan gangguan

  • GitHub mengumumkan bahwa insiden telah diselesaikan setelah menyelidiki laporan penurunan performa pada Issues dan Webhooks
  • Gangguan ini berdampak pada Git Operations, Webhooks, Issues, Pull Requests, Actions, Packages, Pages, dan Codespaces
  • GitHub menyampaikan terima kasih kepada pengguna yang telah menunggu selama penanganan masalah dan menyatakan bahwa analisis akar penyebab yang lebih rinci akan dibagikan saat sudah siap

Perkembangan

  • Awal investigasi

    • Pada 4 Mei 2026 pukul 15:45 UTC diumumkan bahwa laporan penurunan performa pada Issues dan Webhooks sedang diselidiki
    • Pada 15:48 UTC diumumkan perluasan investigasi terhadap peningkatan latensi dan timeout di beberapa layanan GitHub

  • Perluasan layanan terdampak

    • Pada 15:48 UTC diumumkan bahwa Git Operations mengalami penurunan performa
    • Pada 15:50 UTC diumumkan bahwa Packages mengalami penurunan performa
    • Pada 15:51 UTC diumumkan bahwa Actions mengalami penurunan performa
    • Pada 15:51 UTC diumumkan bahwa Pull Requests mengalami penurunan ketersediaan
    • Pada 15:56 UTC diumumkan bahwa Pull Requests mengalami penurunan performa
    • Pada 16:05 UTC diumumkan bahwa Codespaces mengalami penurunan performa
    • Pada 16:06 UTC diumumkan bahwa Pages mengalami penurunan performa

  • Pemulihan dan mitigasi

    • Pada 16:25 UTC diumumkan bahwa Git Operations telah kembali beroperasi normal
    • Pada 16:28 UTC diumumkan bahwa Actions dan Packages telah kembali beroperasi normal
    • Pada 16:29 UTC diumumkan bahwa Pages telah kembali beroperasi normal
    • Pada 16:29 UTC diumumkan bahwa latensi di seluruh layanan telah kembali normal, dan investigasi akar penyebab serta pencegahan agar tidak terulang masih terus dilakukan
    • Pada 16:32 UTC diumumkan bahwa Pull Requests telah kembali beroperasi normal
    • Pada 16:34 UTC diumumkan bahwa penurunan performa yang memengaruhi Issues telah dimitigasi dan sedang dipantau untuk memastikan stabilitas
    • Pada 16:35 UTC diumumkan bahwa penurunan performa yang memengaruhi Codespaces telah dimitigasi dan sedang dipantau untuk memastikan stabilitas
    • Pada 16:35 UTC diumumkan bahwa Webhooks telah kembali beroperasi normal

  • Terselesaikan

    • Pada 16:36 UTC diumumkan bahwa penurunan performa telah dimitigasi dan sedang dipantau untuk memastikan stabilitas
    • Pada 16:40 UTC status insiden diubah menjadi terselesaikan
    • Analisis akar penyebab yang terperinci akan dibagikan segera setelah tersedia

Bacaan terkait

1 komentar

 
GN⁺ 2 jam lalu
Komentar Hacker News

  • GitHub mengungkap angka lonjakan penggunaan yang mengejutkan sambil menyebut peningkatan coding berbasis agen, dan pada akhirnya tampaknya mereka harus mengubah pembatasan laju, mengurangi jatah tier gratis, atau mencari cara lain untuk menurunkan beban
    Jelas terlihat infrastrukturnya tidak mampu mengikuti laju pertumbuhan ini, dan kecil kemungkinan GitHub akan terus menanggung kenaikan biayanya begitu saja. Penasaran bagaimana GitHub akan berkembang ke depannya

    • Pada 3 April, COO GitHub sudah mengatakan bahwa aktivitas di platform sedang melonjak tajam
      Pada 2025 ada 1 miliar commit, dan sekarang sudah 275 juta per minggu, jadi bahkan dengan kenaikan linear saja ritmenya tahun ini setara 14 miliar. GitHub Actions juga naik dari 500 juta menit per minggu pada 2023 menjadi 1 miliar menit per minggu pada 2025, dan minggu ini sudah mencapai 2,1 miliar menit
      Mereka katanya mendorong sangat agresif penambahan CPU, perluasan layanan, dan penguatan fungsi inti GitHub
      https://x.com/kdaigle/status/2040164759836778878
      Ada juga tulisan blog terbaru soal ketersediaan: https://github.blog/news-insights/company-news/an-update-on-...
      Masalah skalabilitas yang dihadapi para engineer GitHub tampaknya benar-benar tidak ringan
    • Dari pengamatan selama puluhan tahun, ada sistem yang membuat tiap pekerjaan menjadi murah dan ada sistem yang mati-matian melakukan scale-out horizontal, dan yang pertama sering kali menang besar atas yang kedua
      Misalnya, GitHub tampaknya mengimplementasikan halaman /pulls repositori seperti query pencarian, dan kolom pencarian yang sudah terisi sebelumnya adalah petunjuknya; saat backend pencarian sempat bermasalah minggu lalu dan pull request tidak bisa dimuat, hal itu nyaris terkonfirmasi. Padahal ini bisa diimplementasikan dengan panggilan API biasa yang hanya mengambil pull request terbuka, API itu ada, dan saat itu tidak ikut bermasalah
      Jika GitHub fokus mencari pekerjaan kelas atas 95% seperti page load dan panggilan API ikutannya lalu mengoptimalkannya, tampaknya hanya dengan penyederhanaan saja beban backend bisa dikurangi lebih dari 5x
      Diff viewer juga tampak punya banyak ruang untuk ditingkatkan. Sebagian besar inefisiensi yang parah mungkin ada di sisi frontend yang tidak langsung membebani backend, tetapi fitur command line git biasa sangat cepat
    • Rasanya sekarang sudah mendekati titik tanpa jalan kembali. Kecuali infrastruktur gratis dan berbayar dipisahkan, saya tidak tahu apakah mereka bisa keluar dari lubang yang mereka gali sendiri hanya dengan scale-out horizontal
      Sama seperti produk pengganti harus 10x lebih baik agar orang mau berpindah, jika produk yang ada menjadi 10x lebih buruk, pesaing bisa mendapat keuntungan 10x secara cuma-cuma hanya dengan diam di tempat
    • Seminggu lalu GitHub memposting hal ini di blog, lalu sehari setelahnya para eksekutif GitHub mengulanginya di komentar HN, dan seketika jadi semacam pengetahuan umum bahwa penurunan reliabilitas sejak 2019 bukan karena integrasi Microsoft pada 2019, melainkan karena sesuatu yang baru muncul pada 2023
      PR memang efektif. Kesimpulannya jadi: GitHub bermasalah karena terlalu sukses
    • Saya sangat mendukung agar seluruh kapasitas server LinkedIn dipindahkan ke GitHub

  • Menurut https://mrshu.github.io/github-statuses, uptime 90 hari terakhir GitHub adalah 84,92%
    Saya tidak paham bagaimana ini bisa dianggap sedikit pun masih dapat diterima

    • Situs itu tampaknya menghitung downtime berlebihan. Bahkan jika hanya difilter ke gangguan major dan critical yang layak masuk halaman depan HN, hasilnya tetap buruk, tapi tidak seburuk 84,92%
      https://isgithubcooked.com/?severities=major.critical
    • Itu memang tidak dapat diterima. Ada banyak hal yang belakangan ini seharusnya tidak dapat diterima, tapi semua orang tampak menerimanya tanpa masalah besar
    • Jangankan three nines, two eights pun tidak tercapai

  • Sekarang performanya sudah sampai tingkat yang sulit diterima. Tidak ada minggu tanpa pekerjaan saya terganggu karena GitHub

    • Agen AI pada dasarnya telah mengubah karakteristik skalabilitas seluruh internet
      Dulu GitHub bisa berasumsi bahwa platform dipakai oleh jumlah orang yang terbatas, dengan pola penggunaan yang manusiawi dan bisa diamati, lalu menskalakan sistem dan mengoptimalkan bottleneck UI/UX berdasarkan pola itu
      Tapi sekarang semua orang punya satu bot yang berjalan 24 jam, kadang bahkan beberapa, sehingga banyak layanan jadi kelebihan beban. Terutama layanan yang kini berpusat pada agen seperti GitHub belakangan ini
    • Beberapa bulan lalu saja ini sudah tidak dapat diterima, dan sekarang rasanya sudah mendekati tahap harus aktif mencari alternatif
    • Bukan seminggu, sekarang rasanya kita harus bersyukur kalau bisa lewat sehari saja tanpa gangguan
      Setiap Senin pagi waktu Pasifik, saya bahkan sudah tidak tahu ini pengulangan yang ke berapa
    • Di Eropa kondisinya jauh lebih baik. Saya sudah selesai bekerja beberapa jam sebelum gangguan ini mulai, dan saya tidak terlalu ingat ada gangguan besar yang sampai menghentikan pekerjaan dalam beberapa bulan terakhir
      Ada satu kali baru-baru ini saat saya mau mengerjakan proyek hobi pada malam hari dan terdampak
    • Menurut saya, batas tidak dapat diterima itu sudah lama terlewati

  • Sekarang posting GitHub down di halaman depan HN sudah sampai level bersaing tiap minggu dengan posting baru yang melebih-lebihkan LLM
    Saya sedang mempertimbangkan memindahkan semua proyek pribadi ke Codeberg. Alasannya bukan cuma stabilitas GitHub, tapi juga karena saya suka ada alternatif yang tidak terikat ketat pada perusahaan big tech

    • Spam paling parah adalah yang mengklaim Claude Code nyaris seperti sihir, tapi sepertinya sempat kalah sorotan oleh posting status GitHub. Mungkin sekarang memang sedang masa jeda iklan Claude
    • Tapi kenyataan bahwa orang masih belum pindah justru menunjukkan masalah platform dominan. Sedikit ketidaknyamanan dan inersia saja sudah cukup untuk membuat tak ada yang pergi
      Begitu pun tanpa penyalahgunaan monopoli, dan di sini saya sedang bicara tentang Microsoft

  • Lucunya, hampir semua hal selain Copilot tampak sedang mengalami penurunan performa. Ini situasi yang membuat lelucon muncul dengan sendirinya

    • Dibanding fitur-fitur yang sedang melambat sekarang, seluruh fungsi Copilot hanya mencakup sebagian kecil dari kegunaannya
    • Copilot kemungkinan benar-benar terpisah dari sisi penyimpanan kode GitHub, berjalan di infrastruktur yang sama sekali berbeda dan tidak sangat bergantung pada Rails monolith

  • Aneh dan agak sedih rasanya karena saya mulai seperti punya indra keenam untuk mendeteksi kapan GitHub mengalami gangguan layanan
    Sekitar satu jam lalu saya menekan “Resolve Conversation” di pull request, beberapa kali gagal, dan pesan error muncul di bagian bawah halaman di luar layar jadi awalnya tidak terlihat. Hampir setiap beberapa tindakan saya harus me-refresh halaman agar server menampilkan perubahan terbaru
    Saya bilang ke rekan kerja bahwa GitHub tampaknya punya masalah di layanan lain yang kemudian merembet ke komentar PR, dan ini bisa berkembang jadi gangguan yang lebih besar

    • Saya baru saja melihat sinyal yang sama di komentar review PR. Saya cek status page, warnanya masih hijau, dan saya menduga itu tidak akan bertahan lama; ternyata benar

  • Tier gratisnya harus dikurangi
    Dalam 2,5 bulan terakhir saya membuat 4.000 commit, dan itu di main. Saya juga mengunggah banyak artefak setiap hari untuk pengujian regresi
    Biayanya 0 dolar

    • Sejujurnya saya tidak suka tier gratis untuk produk SaaS seperti ini
      Dulu saya memakai layanan Git bayar sesuai penggunaan dari GCP saat Google sempat menyediakannya sebentar, karena saya ingin memiliki milik saya sendiri. Tapi semua orang memakai GitHub yang “gratis”, dan seperti banyak layanan Google lainnya, layanan itu tampaknya akhirnya ditutup
      Jadi sekarang saya memang memakai GitHub gratis, tapi sejujurnya saya lebih memilih membayar biaya penyimpanan dan pemakaian ke penyedia cloud besar
    • Kalau begitu, proyek open source yang masih bertahan di sana akan pindah
    • Kalau hanya melihat sisi repositori, itu mendekati 2 menit penggunaan CPU
    • GitHub harus menerapkan pajak kode sampah. Co-authored with Claude? Bayar. Terlalu banyak em dash di komentar? Bayar. Terlalu banyak kode ditulis dalam waktu singkat? Bayar

  • Ini benar-benar mulai mencapai tingkat yang konyol. Status page kadang diabaikan saat menandai semuanya, termasuk Copilot, sebagai “terdampak”, tapi yang harus dilihat adalah bahwa ketersediaan pull request hanya 95,5%, bahkan lebih rendah dari 96,4% milik Copilot
    Bagaimana orang mau diminta menulis komentar “LGTM” kalau mengakses PR saja tidak bisa?

  • Setidaknya orang-orang jadi belajar cara memakai perintah git remote