- Gangguan di seluruh platform Railway berlangsung sekitar 8 jam mulai 19 Mei 2026 pukul 22:20 UTC, dan penyebab langsungnya adalah penangguhan akun produksi Google Cloud
- Dashboard dan API langsung mengembalikan error 503, sementara infrastruktur compute, database, control plane, dan burst-compute yang dihosting di Google Cloud menjadi offline
- Workload Railway Metal dan AWS tetap berjalan, tetapi edge proxy bergantung pada API control plane di Google Cloud sehingga setelah cache route kedaluwarsa, error 404 meluas
- Bahkan setelah akses akun dipulihkan, persistent disk, compute instance, dan networking masing-masing harus dipulihkan secara terpisah, sementara pembatasan laju GitHub OAuth dan webhook kembali menghambat login serta build
- Railway mengakui tanggung jawab atas keputusan arsitektur yang membuat tindakan dari satu penyedia hulu menjalar menjadi gangguan total, dan kini sedang melakukan redesign untuk menghapus Google Cloud dari hot path data plane
- Mulai 19 Mei 2026 pukul 22:20 UTC hingga sekitar 20 Mei pukul 06:14 UTC, Railway mengalami gangguan di seluruh platform selama sekitar 8 jam
- Saat Google Cloud menangguhkan layanan akun produksi Railway, API, control plane, database, dan infrastruktur compute yang dihosting di Google Cloud menjadi offline
- Pengguna langsung mengalami error 503 di dashboard dan API, serta tidak bisa login dengan pesan
"no healthy upstream" dan "unconditional drop overload"
- Semua workload yang dihosting di Google Cloud compute menjadi offline
- Workload di lingkungan Railway Metal dan AWS burst-cloud sendiri tetap berjalan, tetapi edge proxy Railway bergantung pada API control plane yang dihosting di Google Cloud untuk mengisi routing table
- Saat route jaringan yang di-cache kedaluwarsa, workload di luar Google Cloud juga menjadi tidak bisa dijangkau, dan network control plane tidak dapat me-resolve route ke instance aktif sehingga mengembalikan error 404
- Pada puncak dampak, workload Railway di semua region menjadi tidak bisa dijangkau
- Selama pemulihan lingkungan Google Cloud, build dan deployment di seluruh platform terblokir selama proses pemulihan layanan individual
- Setelah seluruh infrastruktur pulih, backlog besar job deployment yang tertunda diproses secara bertahap agar tidak membebani platform
- Pada saat yang sama, GitHub menerapkan pembatasan laju pada integrasi OAuth dan webhook Railway sehingga login dan build sempat terblokir
- Peningkatan volume panggilan merupakan akibat dari cache yang dikosongkan karena gangguan Google Cloud
- Catatan persetujuan syarat layanan juga ter-reset sehingga pengguna harus menyetujuinya lagi saat kunjungan dashboard berikutnya
- Railway mengakui tanggung jawab atas keputusan arsitektur yang memungkinkan tindakan dari satu penyedia hulu menyebar menjadi gangguan di seluruh platform
- 19 Mei 22:10 UTC: Pemantauan otomatis mendeteksi kegagalan health check API dan memberi tahu petugas on-call
- 19 Mei 22:11 UTC: Dashboard mengembalikan error 503 dan pengguna tidak lagi bisa login
- 19 Mei 22:19 UTC: Dikonfirmasi bahwa penyebab akar masalah adalah Google Cloud Platform yang menangguhkan akun produksi Railway
- 19 Mei 22:22 UTC: Tiket P0 diajukan ke Google Cloud dan account manager GCP Railway terlibat langsung
- 19 Mei 22:29 UTC: Insiden dideklarasikan
- 19 Mei 22:29 UTC: Akses akun GCP dipulihkan, tetapi semua compute instance tetap berhenti dan persistent disk tidak dapat diakses
- 19 Mei 22:35 UTC: Saat route jaringan yang di-cache mulai kedaluwarsa, workload Railway Metal dan AWS mulai mengembalikan error 404
- 19 Mei 23:09 UTC: Persistent disk pertama kembali online
- 19 Mei 23:54 UTC: Semua persistent disk dipulihkan ke status ready, tetapi jaringan masih down
- 20 Mei 00:39 UTC: Status ready disk terkonfirmasi, dan pemulihan terhambat oleh pemulihan jaringan Google Cloud
- 20 Mei 01:30 UTC: Compute instance mulai pulih
- 20 Mei 01:38 UTC: Edge traffic mulai dilayani lagi dan jaringan pulih
- 20 Mei 01:57 UTC: Infrastruktur orkestrasi dan build pulih, lalu deployment dihentikan sementara agar job tertunda yang berjalan bersamaan tidak membuat sistem kewalahan
- 20 Mei 02:04 UTC: Host compute pulih online secara bertahap
- 20 Mei 02:47 UTC: GitHub mulai menerapkan pembatasan laju pada integrasi OAuth dan webhook Railway, membuat sebagian pengguna tidak bisa login dan build terblokir
- 20 Mei 02:55 UTC: Dashboard kembali bisa diakses
- 20 Mei 03:59 UTC: Pemrosesan deployment dimulai lagi di semua tier
- 20 Mei 04:00 UTC: Dipastikan API, dashboard, dan endpoint OAuth berfungsi, sementara pemulihan workload yang tersisa terus berlangsung
- 20 Mei 06:14 UTC: Insiden dipindahkan ke tahap pemantauan
- 20 Mei 07:58 UTC: Insiden diselesaikan
-
Penangguhan akun Google Cloud
- Pada 19 Mei pukul 22:20 UTC, Google Cloud secara keliru mengubah akun produksi Railway menjadi status ditangguhkan sebagai bagian dari tindakan otomatis
- Tindakan ini memengaruhi beberapa akun di dalam Google Cloud
- Karena ini merupakan tindakan di tingkat platform, tidak ada kontak awal ke masing-masing pelanggan sebelum pembatasan diberlakukan
- Status penangguhan menonaktifkan infrastruktur terkait GCP, termasuk Railway Dashboard, API, sebagian infrastruktur jaringan, dan tambahan infrastruktur burst-compute yang dihosting di Google Cloud
-
Ketergantungan control plane
- Control plane Railway adalah kumpulan dependensi inti yang menyajikan dashboard, menangani build dan deployment, serta mengisi routing table yang digunakan edge
- Semua workload di Google Cloud langsung terdampak
- Edge proxy Railway menyimpan cache routing table dari network control plane yang dihosting di dalam Google Cloud
- Selama cache masih bertahan, workload di Railway Metal dan AWS tetap melayani traffic
- Begitu cache kedaluwarsa, edge tidak lagi dapat me-resolve route ke instance aktif, dan workload di semua region termasuk Metal dan AWS mulai mengembalikan error 404
- Workload itu sendiri tetap online, tetapi dampak gangguan jaringan menyebar ke region di luar Google Cloud
-
Batasan desain high availability
- Infrastruktur Railway dirancang dengan target high availability, dengan database berjalan di beberapa availability zone dan jaringan memakai koneksi redundan antara AWS, GCP, dan Railway Metal
- Meski akses akun dipulihkan, layanan individual tidak otomatis pulih
- Persistent disk, compute instance, dan networking masing-masing memerlukan pemulihan terpisah, dan karakteristik pemulihan ini membuat gangguan berlanjut beberapa jam lagi
- Disk dipulihkan ke status ready pada 23:54 UTC, tetapi networking inti dan edge routing baru pulih sepenuhnya sekitar 20 Mei pukul 01:30 UTC
- Railway masih menunggu konfirmasi apakah keterlambatan ini dan error terkait berasal dari sisi Google
-
Pemulihan bertahap dan dampak sekunder
- Saat networking pulih, validasi layanan inti Railway dan workload pengguna akhir dilakukan per lapisan
- Deployment dihentikan sementara untuk mencegah overload pada sistem build, lalu dilanjutkan kembali secara bertahap
- Seiring pemulihan sistem inti, GitHub juga menerapkan pembatasan laju pada integrasi OAuth dan webhook Railway
- Karena volume dan karakter burst dari semua request retry, login pengguna dan build sempat terblokir
- Sekitar 20 Mei pukul 04:00 UTC, dipastikan API, dashboard, dan endpoint OAuth berfungsi, sementara pemulihan workload yang tersisa terus berlangsung
-
Desain resiliensi yang sudah ada
- Network control plane Railway dirancang dalam konfigurasi multi-AZ, multi-zone agar tetap bisa berjalan tanpa dampak ke pengguna meski kehilangan beberapa mesin dan komponen
- Desain ini telah diuji di staging dan traffic nyata sebelum dirilis beberapa bulan lalu
- Setelah insiden sebelumnya, Railway terus berinvestasi pada resiliensi, dan hasilnya mereka pernah memulihkan instalasi GitHub pengguna secara stabil tanpa pembatasan laju sekunder
-
Menghapus ketergantungan tunggal
- Jaringan Railway adalah mesh ring yang tersusun dari interkoneksi serat optik high availability antara Metal <> GCP <> AWS
- Bahkan di dalam ring ini, masih ada ketergantungan kuat karena discoverability workload terikat pada API network control plane yang berjalan di mesin Google Cloud
- Mesh tetap berjalan selama sekitar satu jam, tetapi saat cache route kedaluwarsa, ia gagal karena tidak bisa lagi mengisi ulang routing table
- Railway kini sedang segera menghapus ketergantungan ini agar benar-benar menjadi mesh
- Tujuannya adalah memastikan selalu ada jalur antar-cloud meski salah satu interkoneksi terputus
-
Peningkatan database dan failover
- Railway berencana memperluas shard database high availability ke seluruh AWS dan Metal
- Ke depannya, bahkan jika semua instance pada cloud tertentu langsung hilang, quorum database akan tetap menjaga layanan berjalan dan segera melakukan failover untuk workload yang tidak lagi berjalan
-
Redesign data plane dan control plane
- Rencana untuk menghapus layanan Google Cloud dari hot path data plane dan mempertahankannya hanya untuk penggunaan sekunder atau failover sedang berjalan
- Ini berjalan paralel dengan implementasi arsitektur baru untuk data plane yang memungkinkan konektivitas host, serta control plane yang menjalankan dashboard tempat pengguna mengakses dan mengelola Railway
- Upgrade ini bertujuan memastikan layanan inti, terutama komponen yang berhadapan langsung dengan pengguna, tidak bergantung pada satu vendor atau platform mana pun
Tanggung jawab dan kesimpulan
- Tanggung jawab atas pemilihan vendor ada pada Railway, dan pilihan kali ini pada akhirnya juga merupakan tanggung jawab Railway
- Bagi pelanggan, yang dilihat adalah produk itu sendiri, bukan apakah penyebab kegagalan berasal dari Google atau Railway; uptime Railway adalah tanggung jawab Railway
1 komentar
Komentar Hacker News
Bagian yang menarik dan masih belum dijelaskan adalah mengapa Google menandai akun tersebut
Seberapa pun timestamp yang diamati dimasukkan ke postmortem, akar masalahnya tetap tidak dibahas
Pada bagian cerita yang terasa “tidak masuk akal”, besar kemungkinan ada penjelasan nyata yang belum ingin diungkap siapa pun
Google mematikan akun kami tanpa pemberitahuan, padahal saat itu kami menghabiskan sekitar $10.000 per bulan
Bahkan akun premium support kami ikut terkunci, jadi kami bahkan tidak bisa memberi tahu tim support bahwa “kami terkunci”
Sekitar 8 jam kemudian, seorang engineer support Google secara acak mengatakan bahwa itu karena kami menambang bitcoin, yang benar-benar tidak masuk akal
Kami punya grafik penggunaan CPU dan log untuk seluruh periode itu, dan tidak ada lonjakan sama sekali
Sekitar 12 jam kemudian mereka menyalakannya kembali dan mengatakan itu adalah “kesalahan konfigurasi deteksi penyalahgunaan”, lalu memberi kami kredit sekitar $100
Mau bilang apa pun tentang AWS, AWS tidak akan melakukan hal seperti ini ke pelanggan tanpa ada orang yang menghubungi lebih dulu
Sejak saat itu saya tidak percaya GCP
Sistem otomatis memang bisa salah, tapi masalah yang lebih besar adalah sistem itu sepenuhnya tidak transparan
Bisa jadi bahkan Google sendiri tidak tahu persis bagaimana sistem itu bekerja
Jika maksudnya Railway seharusnya mengerahkan tenaga ke sini alih-alih meninggalkan GCP, saya tidak paham mengapa mereka harus melakukan itu kecuali mereka berniat menuntut GCP untuk memulihkan kerugian merek dan retensi pelanggan jangka panjang
Begitu GCP mematikan semuanya tanpa peringatan, menurut saya itu sudah game over, dan tidak perlu ditanya lebih lanjut
Citra Railway di media teknologi bulan ini tampaknya kurang baik
Dalam kedua kasus, reputasinya rusak karena prosedur otomatis pihak lain
Awalnya saya mau bicara ke kontak Google tentang masalah Gemini CLI yang dimatikan, tapi kasus ini jauh lebih mengkhawatirkan
Hanya mereka yang memasukkan kredensial akun admin ke AI
Dan mereka juga tidak mengambil tanggung jawab pribadi, yang jelas merusak reputasi
Kali ini setidaknya mereka mengakui sebagian tanggung jawab, jadi saya akui ada perbaikan
Selain itu, masalah keandalan GCP dan buruknya customer support Google memang benar-benar serius
Edit: saya baru tahu dari bawah bahwa dua paragraf pertama salah atribusi, dan itu bukan Railway melainkan pelanggan Railway. Maaf, Railway!
Perusahaan kami dulu memakai penyedia hosting yang pada dasarnya menambahkan beberapa jaminan ekstra di atas AWS
Sekarang AWS langsung menyediakan fitur yang kami butuhkan, jadi kami sudah selesai bermigrasi ke AWS biasa
Sayangnya, karena kejadian ini kami harus melakukan migrasi darurat ke Azure kemarin
Untungnya kami tidak menaruh database di Railway, jadi kami pulih dalam beberapa jam
Kesederhanaan yang ditawarkan Railway memang sangat bagus, tapi terlalu banyak insiden dan keterbatasan untuk terus menjalankan aplikasi enterprise B2B di infrastruktur itu
Hari yang menyedihkan :(
Saya tidak terlalu mengenal layanannya, tapi apakah Anda memilihnya karena fitur unik, atau pada dasarnya untuk penggunaan seperti virtual machine?
Kalau karena fitur unik, saya juga penasaran seberapa sulit migrasi keluarnya
Untuk SaaS tool kecil atau produk internal, kalau tim tidak ingin mengelola AWS atau penyedia IaaS lain secara langsung, alternatif apa yang bagus?
Bahkan kalau memakai sesuatu seperti AWS, tanpa redundansi lintas availability zone, sesekali akan tetap ada downtime
Bahkan dengan redundansi lintas availability zone, AWS juga tidak sepenuhnya terisolasi, jadi beberapa layanan bisa gagal dan downtime tetap bisa terjadi
Jadi terimalah downtime dan gunakan alat yang paling cocok untuk Anda. Kecuali jika seburuk GitHub
Jika Anda sama sekali tidak bisa menerima downtime, Anda butuh jutaan dolar dan berbulan-bulan kerja untuk mencapai tingkat kepercayaan yang membuat Anda bisa berharap nyaris tanpa downtime
Chaos Monkey milik Netflix dan infrastruktur mereka mungkin sudah cukup
Setidaknya Anda butuh dua penyedia dengan kemampuan operasional penuh
Tanpa tarif bayar sesuai pemakaian pun Anda bisa melangkah cukup jauh
Penyedia cloud besar menawarkan layanan yang hanya sedikit lebih sulit dibanding yang dilakukan Railway, dan bisa berkembang ke fitur yang lebih canggih saat kebutuhan Anda bertambah
Anda tidak perlu menambahkan pihak ketiga yang mengendalikan fitur, keamanan, dan ketersediaan
Misalnya, menurut timeline ini, GCP merespons dalam 7 menit
Kalau mereka memakai Cloud Run, downtime mungkin akan berkurang lebih dari 7 jam, dan jika pemicu yang tidak diketahui itu berkaitan dengan aktivitas pelanggan lain atau perilaku aneh Railway, kemungkinan besar sejak awal tidak akan ikut down
Ada juga kompleksitas
Banyak infrastruktur rumit yang menurut Railway harus mereka perbaiki kemungkinan tidak akan diperlukan jika hanya memakai akun sendiri
Kode itu jelas melakukan hal yang berguna, tetapi untuk penyedia hosting ada banyak komponen bergerak yang perlu, sementara pengguna biasa tidak membutuhkannya
Gangguan kali ini menjatuhkan semua orang bersama-sama, tetapi pengguna AWS individual atau pengguna bare metal pada dasarnya tidak akan terdampak
Tidak ada satu jawaban global yang terbaik untuk semua orang, tetapi developer cenderung sangat meremehkan biaya langsung dan biaya tak terlihat dari bekerja di dalam lingkungan orang lain dibanding waktu yang mereka hemat dengan mengurangi beberapa langkah deployment
“19 Mei 22:10 UTC - pemantauan otomatis mendeteksi kegagalan health check API, memanggil on-call, dan para penanggung jawab mulai menyelidiki”
“19 Mei 22:20 UTC - Google Cloud secara keliru mengubah akun produksi Railway ke status suspend sebagai bagian dari tindakan otomatis”
Jika timestamp-nya akurat, lalu apa yang menyebabkan error 10 menit sebelum suspend akun?
Penjelasan paling sederhana adalah salah satu dari dua timestamp itu keliru, dan itu sendiri bukan masalah besar
Tapi jika mereka tidak yakin soal timestamp-nya, cukup aneh memasukkannya ke laporan seolah sudah pasti padahal jelas saling bertentangan
Bagian timeline yang memuat 22:10 konsisten secara internal, dan juga memuat hal berikut
“19 Mei 22:19 UTC - akar masalah teridentifikasi: Google Cloud Platform menangguhkan akun produksi Railway”
Anda tidak mungkin mengidentifikasi akar masalah sebelum kejadian itu terjadi
Misalnya seorang karyawan Google salah menyentuh konfigurasi dan menciptakan sinyal yang membuat suspend tampak perlu, seperti pada insiden-insiden sebelumnya, lalu butuh 10 menit sampai itu mengalir ke prosedur suspend
Atau pelanggan Railway melakukan sesuatu yang curang atau terlihat curang, lalu sistem Google mulai membatasi akses dan dalam 10 menit memutuskan untuk menaikkannya menjadi suspend
Kalau ada manusia di proses approval-nya, itu malah terasa lebih masuk akal
Hanya saja jelas orang itu tidak menggali cukup dalam untuk melihat bahwa mereka tidak seharusnya melakukan itu
Ini seharusnya menjadi peringatan bagi siapa pun yang menjalankan produksi di GCP
GCP tampaknya menangguhkan akun ke sana kemari tanpa benar-benar memikirkan apa yang mereka lakukan
Rasanya seperti keputusan produksi dijalankan oleh Gemini 3.1 Pro
TK punya rekam jejak merusak budaya organisasi sepenuhnya seperti di OCI, dan dari yang saya dengar, dia tampaknya melakukan hal serupa di GCP
GCP dan Google adalah organisasi yang bekerja dengan cara yang benar-benar berbeda
Jangan berharap kualitas Google hanya karena melihat namanya
Mirip seperti Nokia, sebuah merek lama yang sekarang menempel pada produk berlisensi murah. Memang berlebihan, tapi tidak jauh dari kenyataan
Bukan cuma itu, mereka juga dikenal menutup layanan secara acak sambil memberi masa migrasi sekitar 6 bulan
Ada banyak engineer tanpa pekerjaan jelas sehingga mereka bisa ditugaskan untuk membantu memindahkan pengguna internal keluar dari layanan itu, tapi sebagian besar pelanggan tidak punya kemewahan tersebut
Dulu ada tulisan bagus dari mantan pegawai GCP, tapi sekarang saya tidak bisa menemukannya
Jika Anda serius soal bisnis, hindari GCP seperti wabah
Edit: ironisnya Gemini menemukan tulisan itu. Layak dibaca: https://steve-yegge.medium.com/dear-google-cloud-your-deprec...
Namanya cukup besar sampai bisa naik ke bagian atas halaman utama HN, dan pada titik tertentu mestinya ada orang di Google yang bisa dihubungi untuk turun tangan
Kalau ini produk kecil buatan saya, saya sama sekali tidak akan punya jalan keluar
Kualitas produknya sendiri justru cukup bagus, itu yang membuatnya lebih disayangkan
Mereka seharusnya bisa dengan mudah menjadi penyedia nomor 2, karena Azure sangat tidak stabil dan dokumentasinya di bawah standar
Bahwa GCP ada di posisi 3 sebagian besar adalah akibat ulah mereka sendiri
Penilaian saya yang sepenuhnya tidak berdasar adalah bahwa dia datang sebagai sosok dewasa yang disiplin untuk memperbaiki pendekatan enterprise Google yang terlalu longgar
Seperti yang ditunjukkan insiden ini, jalan mereka mungkin masih panjang, tetapi untuk menjadi organisasi enterprise yang “serius”, mungkin itu memang diperlukan
Hanya saja dalam prosesnya dia mungkin menciptakan budaya yang bertabrakan dengan sisa organisasi Google
Meski begitu, apakah OCI sebagai divisi Oracle memang punya budaya yang layak dihancurkan? Sebaliknya, tampaknya masuk akal kalau TK justru membawa budaya itu ke Google
Jangan pernah dipakai untuk hal yang penting
Ini bukan pertama kalinya Google Cloud benar-benar merusak akun pelanggan: https://cloud.google.com/blog/products/infrastructure/detail...
“Railway bertanggung jawab atas pilihan vendornya, dan pada akhirnya pilihan ini juga merupakan tanggung jawab kami. Pelanggan tidak peduli apakah gangguan ini disebabkan oleh Google atau Railway. Yang pelanggan lihat adalah produk kami. Uptime Anda adalah tanggung jawab kami, dan kami akan terus menyediakannya”
Patut dipuji bahwa mereka mengakui ini, bukan sekadar bahasa PR
Mempercayai GCP adalah kegagalan arsitektur di pihak Railway, dan ini menunjukkan bahwa mereka sedang berusaha memperbaikinya
Haruskah itu sudah diprediksi sebelumnya? Ya. Tapi tetap lebih baik terlambat daripada tidak sama sekali
“Terakhir, kami sedang membuat rencana untuk menghapus layanan Google Cloud dari hot path data plane dan hanya mempertahankannya untuk keperluan sekunder/failover”
Cukup jelas
Google tidak lagi bisa dipercaya sebagai penyedia layanan B2B
Ada perusahaan yang aplikasi OAuth Meta-nya menjadi sepenuhnya tidak bisa dipakai hanya karena akun Facebook pribadi salah satu karyawan developer mereka diblokir Meta tanpa alasan
Mereka sudah berkali-kali melakukan eskalasi, tetapi tidak pernah sampai ke mana-mana
Meta lebih buruk karena akunnya harus “pribadi”
Walaupun ada Business Manager, semua pengguna yang ditambahkan ke sana tetap terikat ke akun Meta/Facebook pribadi
Konyol
Google sudah berkali-kali membuktikan bahwa mereka tidak bisa dipercaya sebagai penyedia layanan justru karena masalah seperti ini
Karena itu mereka harus dipecah menjadi puluhan bagian
Sering kali mereka baru membatalkannya jauh belakangan setelah kemarahan pengguna dipublikasikan dan kasusnya menyebar
Google selalu bertindak seolah tidak punya kewajiban apa pun terhadap pelanggan berbayar
Menurut saya itu bagian yang paling penting
Penyedia cloud tidak akan menangguhkan seluruh akun tanpa alasan