Red Squares yang Menampilkan Gangguan GitHub sebagai Kontribusi

 (red-squares.cian.lol)
1 poin oleh GN⁺ 1 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • Red Squares memparodikan grafik kontribusi commit GitHub dengan menampilkan gangguan platform GitHub.com dalam kotak merah alih-alih kotak hijau
  • Setiap kotak merah berarti satu hari ketika GitHub mengalami gangguan, dan semakin gelap warnanya, semakin lama gangguan berlangsung pada hari itu
  • Selama 1 tahun terakhir, total downtime GitHub tercatat mencapai 32,5 hari
  • Hari dengan setidaknya 1 insiden berjumlah 167 hari
  • Hari terburuk adalah Kamis, 30 April 2026, dengan downtime mencapai 1,0 hari

Satire grafik kontribusi untuk gangguan GitHub

Bacaan terkait

1 komentar

 
GN⁺ 1 jam lalu
Pendapat Hacker News

  • Setiap kali situs meme vibe coding seperti ini muncul, selalu ada komentar tanpa henti bahwa penyebab sebenarnya bukan beban, melainkan tim GitHub, tech stack, Microsoft, dan Azure yang buruk
    Kalau membandingkan halaman status GitHub publik dengan halaman Enterprise Cloud, metrik di sisi Enterprise jauh lebih baik, dan secara pribadi saya bahkan tidak ingat kapan terakhir kali ada gangguan sampai-sampai saya tidak bisa bekerja
    Jika masalahnya tidak ada kaitannya dengan beban, seharusnya problem uptime yang sama juga terlihat pada produk Enterprise

    • Mengkritik kegagalan menyediakan layanan dengan baik bukan berarti menyalahkan engineer perorangan, melainkan mengkritik kegagalan sistem
      Terutama jika itu perusahaan dengan sumber daya lebih besar daripada banyak negara dan talenta teknik kelas dunia, kritik terhadap sistem sangat layak dilakukan
      Tech stack GitHub memang tidak bagus, dan sudah lama dibela dengan cukup arogan
      Azure adalah platform yang buruk, tetapi dipaksakan ke tim, dan saya juga pernah melihat sikap defensif soal pilihan database relasional maupun penulisan ulang frontend
      Kalau situsnya sendiri bahkan tidak bisa dijaga tetap stabil, menulis ulang UI dan mendorong alat AI hanyalah buang waktu
      Ini bukan menyerang engineer secara pribadi, melainkan mengkritik pilihan manajemen ketika sebuah sistem yang pada praktiknya menjadi monopoli karena efek jaringan memprioritaskan fitur baru atau kepuasan pemilik di atas produk inti
    • Sudah umum diketahui bahwa halaman status resmi tidak mencerminkan downtime sebenarnya apa adanya karena perjanjian tingkat layanan
      Karena halaman status bisa dipakai sebagai bukti yang merugikan perusahaan, perbandingan itu sendiri tidak terlalu berarti
      Dalam praktiknya, yang sebenarnya gangguan sering disebut “penurunan performa” dalam bahasa pemasaran, dan halaman status yang dijalankan secara independen jauh lebih berguna
    • Sepertinya kita bekerja di area yang berbeda
      Mungkin bukan setiap hari, tetapi saya hampir tidak ingat pernah melewati seminggu di kantor tanpa harus menyiasati gangguan
      Dalam kebanyakan kasus, “pekerjaan” tetap bisa lanjut, tetapi hal-hal yang seharusnya sudah build atau deploy dalam waktu yang sama jika tidak ada gangguan jadi tertunda, jadi secara pribadi saya terdampak setidaknya sekali seminggu
    • GitHub bukan toko kecil, jadi kalau ini perusahaan 3 triliun dolar, mereka seharusnya bisa menangani beban itu
      Kalau tidak, setidaknya harus ada peringatan besar di atas yang berbunyi “hanya untuk penggunaan hobi”
    • Ironisnya, tepat saat ini di organisasi saya tidak bisa membuat thread baru di PR karena bug GitHub
      Saya masih bisa membalas thread yang sudah ada, tetapi tidak bisa membuat yang baru, dan itu juga muncul di halaman status
      Saya tidak paham bagaimana hal seperti ini bisa lolos, dan juga sulit mengerti kenapa ini sudah berlangsung satu jam
      Katanya perbaikannya masih butuh 3–4 jam lagi, baik sekali

  • Menyalahkan GitHub bahkan untuk penurunan performa model eksternal seperti Gemini 2.5 Pro, Grok Code Fast 1 in Copilot, dan Claude Opus 4 rasanya tidak adil
    Sepertinya itu masalah yang memang tidak bisa ditangani GitHub

    • Pola belakangan ini adalah mengumpulkan semua penurunan performa kecil dari layanan individual lalu menampilkannya seolah semuanya sama penting
      Tingkat keparahannya dihapus, lalu semuanya diringkas menjadi “gangguan GitHub” atau grafik uptime
      Saya memang tidak puas dengan gangguan besar GitHub belakangan ini, tetapi makin banyak situs pencari perhatian dan postingan sosial yang mengaburkan batas antara degradasi layanan kecil dan situs yang benar-benar mati total agar terlihat lebih dramatis dan mengumpulkan rekomendasi, like, karma, dan perhatian, itu tidak enak dilihat
    • Mengaitkan penurunan performa hyperscaler dengan ketersediaan github.com tidak terlalu menarik
      Kelihatannya seperti ingin membuat grafik semerah mungkin
    • Kalau GitHub membungkus ulang dan menyediakan layanan lain, menurut saya menyalahkan GitHub tetap sah
      Kami menjalankan layanan yang jauh lebih kecil daripada GitHub, tetapi tetap menyiapkan jalur alternatif lewat beberapa penyedia dan beberapa model
    • Itu tergantung siapa yang meng-host modelnya

  • Akhir pekan masih merupakan frontier yang belum dijelajahi
    Masih ada ruang untuk diperluas

    • Saat menganalisis bulan lalu, uptime GitHub pada hari kerja adalah 89,3%, dan akhir pekan 96,5%
      Gangguan tersebar di 62% hari kerja dan 11% akhir pekan, dan Claude juga mirip dengan 92,5% pada hari kerja dan 97,8% di akhir pekan
      Selasa sampai Kamis adalah zona berbahaya, dan Minggu nyaris terlihat seperti layanan yang berbeda
      https://www.aakash.io/tech-chase/github-and-claude-are-down-...
    • Jadi, apakah perubahan adalah penyebab terbesar?
    • Tinggal tunggu sampai sistem kerja 996 dimulai

  • Saya meragukan dulu apakah grafik ini akurat
    Tertulis “170 hari dengan setidaknya satu gangguan · hari terburuk Kamis, 20 November 2025, 1,1 hari”, tetapi saya tidak mengerti bagaimana total satu hari bisa menjadi 1,1 hari
    Saat diarahkan ke tanggal itu, cara hitung internalnya juga tidak terlihat, dan satu entri tunggal ditampilkan sebagai 1,3 jam
    Pada 19 November, ada entri gangguan 1,3 hari tetapi totalnya ditampilkan sebagai 8,1 jam

    • Halaman status yang hilang [1] menghitung downtime jika komponen sistem apa pun sedang down, lalu menghitung total uptime berdasarkan waktu yang tidak saling tumpang tindih, dan waktu yang bertumpang tindih dengan setidaknya satu insiden individual dihitung sebagai total downtime untuk menghindari penghitungan ganda
      Untuk tanggal itu ditampilkan sebagai 24 jam gangguan ringan
      Situs ini tampaknya menjumlahkan downtime semua layanan dalam satu hari, dan jika begitu, hari terburuk bisa mencapai 10 hari downtime karena downtime harian dari tiap kategori utama dijumlahkan
      1: https://mrshu.github.io/github-statuses/
    • Saya melihat entri “1,0 hari dari 1,3 hari”, dan saat mengarahkan kursor ke hari sebelumnya, Rabu 19 November 2025, muncul “7,8 jam dari 1,3 hari”
      Saya belum memeriksa apakah memang ada downtime hari itu, tetapi jika angkanya benar, 7,8 jam ditambah 1 hari kira-kira menjadi 1,3 hari

  • Perbedaan antara halaman status resmi [0] dan halaman status pihak ketiga [1] terlalu besar
    Kalau kondisi pemakaian produk nyata berbeda sejauh ini, saya jadi bertanya-tanya bagaimana ketentuan perjanjian tingkat layanan bisa legal
    Saya suka GitHub dan layanannya, tetapi setiap kali status page berwarna hijau padahal sebenarnya sedang rusak, ada sesuatu dalam diri saya yang berteriak
    [0] https://www.githubstatus.com/
    [1] https://mrshu.github.io/github-statuses/

    • Ketentuan itu legal karena dalam perjanjian tingkat layanan, pihak yang harus melacak ketersediaan dan menuntut kredit jika terjadi pelanggaran adalah pelanggan
      Di tempat kerja saya yang terakhir, kami sering mengalami gangguan GitHub yang tidak tercatat di halaman status, dan saya menyimpan lognya lewat pencarian Slack
      Setelah itu orang-orang bisnis berdebat dengan account representative GitHub dan akhirnya mendapat kredit beberapa ratus dolar
      Tetapi mereka mengeluh bahwa kredit beberapa ratus dolar itu tidak sebanding dengan waktu yang sudah dihabiskan, jadi uptime GitHub yang rendah terus berlanjut dan tidak ada yang terjadi
    • Lucunya, saat masalah meledak kemarin, rekan kerja saya menautkan halaman mrshu, tetapi ketika halaman resmi menandai masalah Actions, halaman itu justru semuanya hijau
    • Ada kemungkinan perjanjian tingkat layanan tidak memasukkan sebagian fungsi GitHub ke dalam cakupan
      Sebaliknya, halaman pihak ketiga bisa menganggap gangguan atau masalah pada satu model tertentu sebagai masalah GitHub, jadi hasilnya bisa berbeda dari penggunaan nyata

  • Pada akhir pekan, gangguan jauh lebih sedikit
    Toh saya memang tidak berniat bekerja saat itu, jadi sempurna

  • Ide ini sudah ada sejak lama
    Pada bulan Januari saya membuat ini untuk memecah uptime berdasarkan kategori gangguan
    https://isgithubcooked.com

    • “Billing” sepenuhnya hijau, dan “Pull Requests” sepenuhnya merah

  • Lucu juga karena hampir tidak adanya downtime di akhir pekan terlihat sangat mirip dengan grafik kontribusi