Gangguan Fly.io telah diselesaikan

 (status.flyio.net)
1 poin oleh GN⁺ 2024-11-27 | 1 komentar | Bagikan ke WhatsApp
  • Halaman status Fly.io saat ini menunjukkan All Systems Operational, dan komponen utama seperti eksekusi aplikasi, dashboard, Machines API, serta ketersediaan regional sedang beroperasi
  • Elevated API Errors pada 1 Jul 2026 diselesaikan pada 07:50 UTC setelah perbaikan error GraphQL API dan masalah pemrosesan pekerjaan latar belakang
  • Delayed Metrics pada 30 Jun menyebabkan metrik tertunda atau hilang di dashboard fly-metrics.net untuk sebagian pelanggan, lalu kembali normal setelah pemrosesan backlog dan penambahan kapasitas
  • Halaman status ini ditujukan untuk pembaruan gangguan global, sehingga kegagalan perangkat keras dengan dampak terbatas atau insiden infrastruktur yang terisolasi tidak disertakan
  • Dampak per aplikasi harus diperiksa di personalized status page pada dashboard Fly Organization, dan untuk insiden internal serta aktivitas lainnya diarahkan ke Infra Log

Status layanan saat ini

  • Halaman status Fly.io saat ini berada dalam status All Systems Operational
  • Item utama yang ditandai beroperasi adalah Customer Applications, Dashboard, Machines API, Regional Availability, Persistent Storage (Volumes), Deployments, Remote Builds, Logs, Metrics, SSL/TLS Certificate Provisioning, UDP Anycast, Fly Machine Image Registry 1·2, Extensions, Upstash for Redis, DNS, Billing, Managed Postgres
  • Status regional juga ditandai beroperasi, dengan wilayah AMS, ARN, BOM, CDG, DFW, EWR, FRA, GRU, IAD, JNB, LAX, LHR, NRT, ORD, SIN, SJC, SYD, YYZ

Cakupan halaman status

  • Halaman ini digunakan untuk pembaruan global incidents
  • Pembaruan untuk kegagalan perangkat keras rutin dengan dampak terbatas atau insiden infrastruktur terisolasi tidak disertakan
  • Tampilan yang dipersonalisasi untuk semua peristiwa yang dapat memengaruhi aplikasi harus diperiksa di personalized status page pada dashboard Fly Organization
  • Untuk insiden internal dan aktivitas lainnya, pengguna diarahkan untuk melihat Infra Log

1 Jul 2026: Elevated API Errors

  • Elevated API Errors ditandai Resolved pada 1 Jul, 07:50 UTC
  • Pada 06:14 UTC, investigasi dimulai terhadap elevated errors pada GraphQL API dan pemrosesan pekerjaan latar belakang
  • Pada 06:27 UTC, penyebabnya diidentifikasi dan perbaikan mulai dikerjakan
  • Pada 07:05 UTC, perbaikan diterapkan dan elevated API errors tidak lagi terlihat
    • Beberapa pekerjaan dashboard sempat dapat tertunda sementara pemrosesan latar belakang mengejar ketertinggalan
  • Pada 07:26 UTC, pekerjaan latar belakang telah mengejar backlog, dan API terus dipantau dalam status beroperasi penuh

30 Jun 2026: Delayed Metrics dan egress IP SIN/NRT

  • Delayed Metrics diselesaikan pada 30 Jun, 22:19 UTC
  • Terjadi masalah pada metrik pelanggan di dashboard fly-metrics.net, sehingga pengguna dapat melihat metrik yang tertunda atau hilang
  • Keterlambatan pengumpulan metrik terjadi karena masalah pada beberapa host, dan resource contention pada sebagian metrics ingestion hosts ditangani sebagai penyebabnya
  • Untuk memproses backlog, throughput metrics cluster ditingkatkan, lalu dilakukan penyesuaian ulang ingestion traffic dan penambahan kapasitas pemrosesan
  • Pada 30 Jun, 19:58 UTC, hampir semua metrik telah mengejar ketertinggalan, tetapi masih ada sejumlah kecil metrik dari sin dan syd
  • Egress IP issues in SIN and NRT diselesaikan pada 30 Jun, 14:03 UTC
    • Sebagian Machines yang menggunakan egress IP di SIN dan NRT sempat kehilangan koneksi atau mengalami penurunan performa untuk sementara

26~25 Jun 2026: Insiden jaringan, deployment, dan control plane

  • IPv6 Connectivity Issues in EWR diselesaikan pada 26 Jun, 23:48 UTC
    • Terjadi masalah konektivitas jaringan IPv6 dari upstream provider di EWR
    • Aplikasi dengan Machines pada host yang terdampak dapat terpengaruh saat terhubung ke tujuan IPv6 tertentu
  • Network maintenance in YYZ adalah pemeliharaan terjadwal yang berlangsung pada 26 Jun, 08:00~09:00 UTC dan telah selesai
    • Dalam jendela pemeliharaan tersebut, diperkirakan dapat terjadi kehilangan koneksi hingga 15 menit
  • Deploys defaulting to Fly-hosted Builders diselesaikan pada 25 Jun, 15:38 UTC
    • Saat menyelidiki keterlambatan provisioning Depot backed builders, strategi default fly deploy dialihkan ke Fly-hosted builders
    • Pengguna dapat memaksa deployment berbasis Depot dengan fly deploy --depot=true, dan setelah itu deployment berbasis Fly builder juga dapat dilakukan dengan fly deploy --depot=false
  • Elevated control plane latency diselesaikan pada 25 Jun, 15:18 UTC
    • Terjadi control plane latency dan saturation yang memengaruhi wilayah BOM dan NRT
    • Aplikasi dengan Machines di wilayah tersebut dapat mengalami waktu respons yang lebih lama dan kemungkinan 502 errors

24~17 Jun 2026: Jaringan Amerika Utara, SIN/NRT, dan pencarian log

  • Degraded networking in North America diselesaikan pada 24 Jun, 06:57 UTC
    • Penurunan performa jaringan antarlokasi di Amerika Utara diselidiki karena insiden upstream
    • Sebagian Machines dapat mengalami packet loss dan latensi lebih tinggi pada rute tertentu
    • Masih ada dampak tersisa pada sebagian traffic 6PN Private Networking dari dan ke wilayah LAX
  • Network issues in SIN, NRT diselesaikan pada 22 Jun, 21:56 UTC
    • Upstream provider mengalami masalah jaringan di wilayah SIN dan NRT, dan aplikasi di wilayah tersebut dapat menjadi tidak dapat dijangkau atau mengalami packet loss tinggi
  • SIN, NRT network issues diselesaikan pada 22 Jun, 19:48 UTC
    • Awalnya diselidiki sebagai upstream network issue di wilayah SIN, lalu diketahui aplikasi di wilayah NRT juga dapat mengalami masalah menjangkau tujuan tertentu
  • Log search unavailable diselesaikan pada 19 Jun, 21:53 UTC
    • Berdampak pada panel pencarian log Fly Metrics dan historical application logs yang pertama kali dikembalikan oleh perintah fly logs
    • Streaming fly logs, halaman Live Logs di dashboard, dan layanan Fly Log Shipper tetap berfungsi normal
    • Setelah perbaikan, historical logs di-backfill dan sebagian besar queued historical logs menjadi dapat dicari
  • Network Issues in SIN diselesaikan pada 17 Jun, 04:55 UTC
    • Terjadi masalah konektivitas jaringan di wilayah SIN dan hosted apps dapat tidak tersedia
    • Sebagian Machines tidak dapat dijangkau, dan beberapa cluster Managed Postgres dapat gagal melakukan fail-over atau update

Bacaan terkait

1 komentar

 
GN⁺ 2024-11-27
Pendapat Hacker News

  • Situs web saya yang dihosting di fly.io down selama 5 menit sekitar 6 jam yang lalu, lalu langsung pulih, dan sejak itu terus normal
    Layanan monitoring gratis mengecek setiap 5 menit, jadi mungkin saja melewatkan downtime yang lebih singkat, tetapi secara keseluruhan cukup stabil

    • Akan menarik jika melihat data beberapa bulan
      Uptime aplikasi juga tidak stabil, tetapi yang lebih buruk adalah kasus ketika fly deploy gagal tanpa alasan. Kadang sebuah layer hanya berhenti begitu saja lalu akhirnya gagal, dan 1–2 jam kemudian, menjalankan ulang perintah yang sama tanpa perubahan apa pun bisa berjalan normal
      Saya ingin melihat layanan monitoring yang men-deploy aplikasi dasar setiap 5 menit, yakni menjalankan perintah fly deploy secara berkala untuk melihat seberapa sering deployment gagal atau macet. Kira-kira sekitar 5% mungkin gagal tanpa penjelasan, dan kalau waktu tidak longgar, itu cukup menjengkelkan
    • Saya memantau fly.io dan dokumentasinya dari luar: https://flyio.onlineornot.com/
      Menurut acuan ini, tampaknya berlangsung 16 menit
    • Kami juga mengalami hal serupa: down sekitar 5 menit lalu pulih, setelah itu baik-baik saja, dan error-nya adalah 501

  • fly.io memublikasikan postmortem di sini: https://fly.io/infra-log/
    Postmortem terbaru cukup menarik dan sangat rinci. Pada 2016, komponen inti infrastruktur operasional fly.io adalah server TLS berkeamanan tinggi bernama consul, yang melacak shared state sekaligus harus mengautentikasi sertifikat server dan sertifikat klien
    Karena arsitekturnya tersentralisasi, muncul masalah skalabilitas, dan pada 2020 fly.io membuat penggantinya, corrosion, lalu dengan cepat melupakan consul, tetapi tidak berhasil menghapusnya sepenuhnya
    Kemudian pada Oktober 2024, signing key untuk root key consul kedaluwarsa, membuat semua koneksi terputus, dan karena memakai autentikasi dua arah, pemulihan tidak bisa dilakukan sebelum sertifikat SSL baru didistribusikan ke seluruh mesin. Entah bagaimana mereka berhasil melakukannya dalam 30 menit, tetapi domino sudah mulai jatuh dan kelemahan lain di infrastruktur juga terungkap
    Layanan internal lain ternyata memiliki set kunci TLS independen yang sudah lama kedaluwarsa, tetapi hal itu tidak diketahui sampai layanan tersebut direstart dalam proses penerbitan ulang kunci consul. Koneksi TCP yang dibuat saat sertifikat masih valid terputus karena restart, sehingga masalahnya terlihat. Sementara itu, tool logging mereka menghantam penyedia jaringan seperti DDoS. Orang-orang yang berhasil menyelamatkan perusahaan sekaligus melindungi pelanggan ketika begitu banyak hal meledak sekaligus benar-benar luar biasa

    • Terkait insiden Consul itu, Fly Infra menyimpulkan bahwa “pelajarannya adalah tidak ada lagi langkah setengah-setengah”
      Namun di halaman rekrutmen [1], mereka berkata “kami tidak terlalu percaya pada technical debt”
      Dari luar, ini terbaca seperti paduan suara kontradiksi
      [1] https://fly.io/docs/hiring/working/#we-re-ruthless-about-doi...

  • Fly.io terlihat sebagai layanan yang cukup bermuka dua
    https://news.ycombinator.com/item?id=41917436
    https://news.ycombinator.com/item?id=35044516
    https://news.ycombinator.com/item?id=34742946
    https://news.ycombinator.com/item?id=34229751
    Kalau sebuah platform cloud tidak bisa memberikan reliabilitas dengan benar, menurut saya nilainya tidak sepadan. Bisa jadi lebih baik menyewa server virtual biasa dan menghemat pajak cloud

    • Untuk eksperimen atau proyek hobi, proposisi nilainya sangat bagus. Di mana lagi bisa menjalankan instance independen dengan $1.94 per bulan
      Namun, harga ini untuk instance dengan RAM 256MB (https://fly.io/docs/about/pricing/). Meski begitu, sangat mungkin menjalankan proyek yang bermakna di atasnya. Web server berbasis Rust seperti Rocket hanya membutuhkan sekitar 10MB RAM, dan dari yang saya temukan, server PHP dasar juga bisa muat
    • Reliabilitasnya benar-benar sangat buruk. Dalam beberapa bulan terakhir, dasbor utama turun dua kali saat saya sedang demo, itu tidak masuk akal
      Bukan hanya gangguan deployment, hampir setiap hari ada saja sesuatu yang secara acak tidak berfungsi atau terlambat
      Karena kenaikan harga dan karena atasan saya beberapa kali melihat masalah pada proyek yang saya taruh di Fly, saya terpaksa pergi beberapa bulan lalu
      Selain itu, layanan backup sqlite juga mereka hentikan dan hapus. Sekarang saya kembali ke GCP dan tidak mengkhawatirkan begitu banyak gangguan
    • Saya tidak benar-benar memahami proposisi nilai fly.io. Meski ada gangguan, tim engineering-nya mengesankan, tetapi apakah edge computing benar-benar dibutuhkan oleh 99,9% developer?
      Banyak layanan perusahaan besar yang beroperasi dari satu region AWS dan digunakan oleh jutaan orang di seluruh dunia. Rasanya seperti sesuatu yang sejak default sudah memungkinkan optimasi prematur
    • Sudut pandang ini sepenuhnya masuk akal, dan saya tidak akan mencoba membantahnya. Kami sedang membangun sesuatu yang sangat sulit, perusahaan kami relatif baru, dan kami bahkan tidak memiliki sebagian kecil dari sumber daya hyperscaler. Bahkan dibandingkan saat AWS, GCP, dan OCI memulai
      Jika mengoptimalkan untuk tujuan memaksimalkan reliabilitas, itu juga pilihan yang sepenuhnya masuk akal. Saya tidak akan mengatakan bahwa pada 2024 kami lebih baik di UE1
      Sebagai referensi, banyak hal bisa salah dan memang terjadi, tetapi bentuk gangguan yang paling mungkin sering Anda lihat di sini adalah periode ketika deployment tidak bisa dilakukan. Gangguan kali ini adalah gangguan deployment/orkestrasi. Beberapa bulan lalu kami menginjak ranjau konkurensi Rust sehingga seluruh routing request terganggu, tetapi hal seperti itu sangat jarang
      Gangguan deployment dan update status juga masalah besar, dan jika Anda terus melakukan deployment ke berbagai grup Fly Machines seperti yang kami sarankan, itu bisa memengaruhi ketersediaan karena merupakan salah satu fitur besar platform. Saya tidak bermaksud mengecilkan hal ini
    • fly.io punya reputasi yang sangat buruk dalam hal reliabilitas, dan di luar Hacker News tampaknya tidak banyak pemulihan citra. Bahkan di sini pun konsensusnya tampak mendekati “jangan jalankan pekerjaan penting di fly.io dan jangan berharap redundansi data”
      Sebenarnya, dengan menjalankan Firecracker di server bare-metal sendiri, Anda bisa melakukan hampir hal yang sama seperti fly.io dengan biaya lebih murah
      Persepsi publik terhadap fly.io sepertinya sudah ternoda sampai sulit dipulihkan. Saya bahkan sudah tidak bisa menghitung berapa kali mereka meminta maaf

  • Berbeda dengan judul tulisannya, Fly.io API masih belum bisa diakses. Artinya pengguna masih belum bisa mengakses deployment, database, dan lain-lain
    Update yang akurat bisa dilihat di https://community.fly.io/t/fly-io-site-is-currently-inaccess...

  • Dari pengalaman pribadi memakai Fly.io dan Railway.com, Railway menang telak. Dukungan Railway juga sangat bagus jika dibandingkan
    Fly.io sampai sekarang belum menjawab pertanyaan penghapusan data yang saya kirim ke email support
    Aplikasi Railway sejauh ini tetap online tanpa downtime besar. Untuk orang yang mencari alternatif yang layak, saya sarankan mencoba Railway

    • Saya mungkin sudah memakai control panel Railway total sekitar 10 kali seumur hidup, dan setengahnya mengalami masalah aneh. UI control panel tidak muncul atau tidak berfungsi, task gagal, deployment gagal secara acak
      Idenya bagus, tetapi dalam praktiknya saya tidak ingin menggunakannya untuk keperluan serius
    • Fly dibangun di atas hardware mereka sendiri. Apakah Railway juga seperti itu? Jika tidak, itu menjelaskan sebagian alasan mengapa Railway relatif lebih sedikit mengalami gangguan. Karena hal yang perlu direkayasa lebih sedikit
      Saya paham bahwa pengguna akhir menginginkan reliabilitas, dan saya juga tahu Fly punya reputasi buruk meski sudah cukup banyak berinvestasi di area ini selama 2 tahun terakhir. Namun gangguan seperti ini bukan sesuatu yang sifatnya hanya ada pada satu penyedia dan tidak ada pada penyedia lain. Membangun infrastruktur cloud tidak mudah bagi siapa pun

  • Dari yang saya lihat sendiri saja, ini mungkin sudah gangguan besar Fly.io yang ke-5 atau ke-6. Ada banyak gangguan lain juga, dan besar kemungkinan sebagian terlewat begitu saja
    Saya merekomendasikan layanan ini kepada seorang teman, dan dalam dua hari dia mengalami dua gangguan
    Fly.io benar-benar perlu sadar. Mengapa mereka masih belum bisa begitu adalah misteri. Produknya bagus, tetapi kalau ini layanan hosting, stabilitas harus menjadi prioritas mutlak nomor satu. Yang lainnya sekunder

    • Saya mengerti, tetapi kalau orang-orang bisa memaklumi GitHub yang mengalami masalah besar setiap dua minggu, saya rasa Fly juga bisa diberi sedikit itikad baik. Saya sama sekali tidak terkait dengan Fly, tetapi kalau perusahaan raksasa pun tidak bisa melakukannya dengan benar, kita perlu menurunkan ekspektasi
      Rahasianya sepertinya adalah menjadi pemain lama yang tidak punya pengganti memadai. Kalau begitu, meski reliabilitasnya benar-benar berantakan, semua orang akan memaklumi kegagalan operasional begitu saja
    • Saya pergi sekitar 1 tahun lalu karena masalah reliabilitas. Sekarang saya memakai DigitalOcean Apps dan berjalan sangat baik. Di DO, downtime-nya 0
    • Jika skala traffic tumbuh secara eksponensial, menjaga reliabilitas memang sulit
    • Apakah ada orang yang benar-benar memakainya di luar free tier? Vercel juga sama

  • Yang mencurigakan, Turso juga mulai mengalami masalah hampir pada waktu yang sama. CEO-nya mengonfirmasi di Discord bahwa itu karena insiden Fly

    Ok.I caught up with our oncall and This seems related to the Fly.io incident that is reported in our status page. Our login does call things in the Fly.io API
    we are already in touch with Fly and will see if we can speed this up

    • Ini bukan pertama kalinya Turso down karena masalah Fly. Mereka membuat layanan database, jadi downtime seperti ini pasti sangat menyakitkan
      Tampaknya Turso suatu saat akan menawarkan tier AWS

  • Tidak mengejutkan. Sekitar setahun lalu saya melihat-lihat fly.io karena harganya murah, dan penasaran dari mana mereka memangkas biaya agar bisa menghasilkan uang. Akhirnya saya menemukan jawabannya di dokumentasi teknis: di sana tertulis jelas bahwa instance fly terikat pada satu server fisik dan jika server itu mati, failover tidak bisa dilakukan. Saya tidak tahu apakah bagian itu masih ada di dokumentasi resmi
    Dalam praktiknya, itu berarti ketika server down, snapshot terakhir instance tersebut harus diambil dari backup, dinaikkan ke server baru, jalur jaringan diperbarui, lalu berharap jumlah server yang mati tidak melebihi kapasitas cadangan. Kalau tidak, pemulihan harus menunggu sampai data center memasang beberapa server lagi ke rack
    Jadi laporan gangguan yang terlihat acak pun cukup bisa dijelaskan. Ada aplikasi yang down sementara aplikasi lain baik-baik saja; ada aplikasi yang kembali dalam 5 menit, sementara yang lain butuh waktu lama
    Kalau bisnisnya punya anggaran ketat, sepertinya opsi lain seperti cluster civo kecil mungkin lebih baik

    • Fly.io sekarang bisa memigrasikan VM dan volume: https://fly.io/docs/reference/machine-migration/ / https://archive.md/rAK0V
      Untuk bagian “instance fly terikat pada satu server fisik sehingga failover tidak mungkin”, saya tidak begitu paham seharusnya seperti apa selain itu. Saya tahu ada live migration, tetapi dalam kasus itu pun bukankah VM pada akhirnya tetap “terikat” pada suatu server fisik?
    • Sebagian besar jenis instance EC2 juga sampai baru-baru ini tidak punya live migration. Beberapa kemungkinan besar masih belum punya. Mereka juga tidak menjelaskan dengan jelas kapan dan bagaimana itu bekerja
      Dan itu tidak gratis. Misalnya, saat VM dimigrasikan di GCP, ada penurunan performa sementara yang terasa
    • Jika ingin high availability di Fly, aplikasi harus dideploy ke beberapa region, artinya ke beberapa machine
      Jika layer proxy gagal, seluruh Fly masih bisa down, tetapi kasus seperti itu jauh lebih jarang
    • Melihat status page, ini tampak seperti kegagalan sistem high availability/clustering. Kali ini sepertinya lebih dekat ke kasus ketika kompleksitas perangkat high availability justru merusak availability sistem dibanding konfigurasi seperti VPS sederhana

  • Pola yang berulang terlihat adalah gangguan sering terjadi pada minggu yang bertepatan dengan hari libur besar di AS
    MS 365/Teams/Exchange juga sempat bermasalah sebentar pada pagi hari, Fly.io mengalami gangguan total, lalu beberapa situs dan layanan lain ikut goyah karena dampaknya
    Biasanya saya menentang “change freeze”, tetapi di sekitar hari libur besar, change freeze terasa masuk akal. Itu bisa memberi semua tim waktu untuk recharge, berhenti sejenak, dan melakukan perawatan
    Sebaiknya jangan memberi tekanan terlalu besar pada tim B yang kebetulan sedang on-call

    • Gangguan sebesar ini jarang disebabkan oleh kode yang buruk. Pelakunya hampir selalu perubahan konfigurasi
      Selama musim liburan, perubahan seperti itu memang bisa coba dikurangi, tetapi bagaimana kalau sertifikat harus diperbarui? Bagaimana kalau patch keamanan penting harus diterapkan? Bagaimana kalau sekumpulan server harus diprovisioning ulang? Bagaimana kalau ruang hard disk hampir habis?
      Kapan pun sepanjang tahun, tantangan operasional tidak bisa dihindari hanya dengan perencanaan
    • Fakta bahwa minggu liburan seperti ini berbeda dari biasanya tidak bisa dihindari. Jika menerapkan “change freeze”, biasanya perbaikan kecil dan tuning performa yang biasa dilakukan di seluruh sistem juga ikut diblokir karena dianggap “tidak penting”
      Lalu pada akhirnya ada dorongan marketing/produk khusus, logika harga khusus membutuhkan kode baru dan widget UI baru, traffic dan load melonjak besar, dan meski sedang freeze, semuanya harus dirilis sekarang juga. Karena terkait pendapatan, itu penting bagi manajemen
      Sebagian besar tim engineering dan infrastruktur tidak tahu soal itu karena tim produk menggebernya sampai menit terakhir dan menjalankannya cukup rahasia. Pada akhirnya, perbaikan kecil berkualitas tinggi bisa dibekukan, tetapi fitur baru yang tidak stabil tidak benar-benar berhasil dibekukan
      Ini memang sulit, tetapi saya tetap menyarankan operasi yang masuk akal: lupakan freeze, dan jangan berlebihan baik sebelum, selama, maupun sesudah periode tersebut
    • Masalah sebentar? 365 punya gangguan yang masih berlangsung sejak kemarin pagi waktu Eropa. Saya tahu karena sedang memakai alat compliance untuk melindungi informasi dalam kasus kebangkrutan besar
    • Itu hanya akan membuat developer buru-buru memasukkan perubahan sebelum freeze
    • “Freeze” itu tepatnya berarti apa? Menghentikan pembaruan sertifikat? Tidak menerima pembaruan keamanan software?
      Perubahan yang “tidak perlu” memang bisa diblokir, tetapi batasnya sangat cepat menjadi area abu-abu

  • Pada rangkaian gangguan awal 2023 juga ada penderitaan terkait Corrosion: https://community.fly.io/t/reliability-its-not-great/11253

    • Sepertinya keputusan membuat data store sendiri adalah taruhan yang buruk
      Saya tidak terlalu memahami constraint-nya, tetapi ScyllaDB mendukung eventual consistency dan secara umum cukup fleksibel. Untuk replikasi multi-leader, CouchDB juga bisa menjadi opsi