Terjadi gangguan jaringan global Cloudflare

• Jaringan global Cloudflare mengalami penurunan performa layanan internal sehingga beberapa layanan terdampak secara intermiten
• Layanan utama seperti Access, Bot Management, CDN/Cache, Dashboard, Firewall, Network, WARP, Workers sempat mengalami gangguan sementara
• Tim engineering mengidentifikasi masalah dan melakukan perbaikan, sementara layanan WARP dan Access dipulihkan lebih dulu
• Setelah itu, tingkat error dan latensi di seluruh dunia berangsur pulih ke level normal, dan layanan dashboard juga dipulihkan
• Saat ini semua layanan beroperasi normal, dan insiden telah sepenuhnya diselesaikan

---

Ringkasan insiden

• Cloudflare mengalami penurunan performa layanan internal (Internal Service Degradation) yang menyebabkan sebagian layanan terhenti secara intermiten
  • Layanan yang terdampak mencakup Access, Bot Management, CDN/Cache, Dashboard, Firewall, Network, WARP, Workers dan lainnya
  • Perusahaan segera memulai pemulihan dan terus memperbarui perkembangan penanganan masalah

Identifikasi masalah dan respons awal

• Cloudflare mengonfirmasi penurunan layanan internal pada tahap Investigating
  • Sebagian pelanggan mengalami error dan latensi secara intermiten
  • Tim engineering menjalankan analisis penyebab dan pemulihan secara paralel
• Setelah itu, penyebab masalah diidentifikasi (Identified) dan perbaikan mulai dilakukan
  • Selama proses perbaikan, akses WARP di wilayah London sempat dinonaktifkan sementara, sehingga pengguna di wilayah tersebut mengalami kegagalan koneksi internet

Progres pemulihan layanan

• Setelah perbaikan, layanan Access dan WARP dipulihkan lebih dulu sehingga tingkat error kembali ke level sebelum insiden
  • Akses WARP di wilayah London diaktifkan kembali
• Setelah itu, pekerjaan pemulihan layanan untuk pelanggan Application Services dilanjutkan
  • Perubahan untuk memulihkan layanan dashboard telah diterapkan
  • Sebagian pelanggan masih mengalami masalah saat login atau menggunakan dashboard, tetapi hal ini diselesaikan dengan perbaikan tambahan

Stabilisasi di seluruh jaringan

• Secara global, tingkat error dan latensi (latency) berangsur menurun dan pulih ke level normal
  • Perhitungan skor Bot Management (bot scores) sempat terdampak sementara, tetapi kembali normal selama proses pemulihan
  • Tim engineering menghilangkan error yang tersisa dan mempercepat pemulihan seluruh jaringan
• Setelah itu, semua layanan kembali beroperasi normal, dan tingkat error serta latensi sepenuhnya kembali normal

Penutupan insiden dan tindak lanjut

• Cloudflare mengonfirmasi bahwa semua layanan beroperasi normal dan menutup insiden ini
  • Saat ini tidak ada perubahan konfigurasi tambahan, dan platform sedang dipantau secara ketat
  • Investigasi pascainsiden (post-incident investigation) terhadap penyebab gangguan sedang berlangsung, dan hasilnya akan dipublikasikan kemudian
• Gangguan kali ini dicatat sebagai insiden yang berdampak pada seluruh jaringan global

[GN⁺]

Komentar Hacker News

• Seseorang membagikan perintah untuk menonaktifkan proxy CF bagi siapa pun yang punya token API Cloudflare
  Dengan perintah curl, Anda bisa mengambil zone ID dan DNS record, lalu mengirim request PATCH dengan "proxied": false
  Namun, perlu hati-hati karena ada risiko kehilangan sertifikat SSL, penurunan keamanan/performa, dan kebocoran IP backend

  • Jika hanya punya Global API Key lama, gunakan header X-Auth-Email dan X-Auth-Key
    Dan bagi yang hanya mengizinkan trafik Cloudflare, aturan itu harus dimatikan sementara
  • Saya sempat berpikir harus memakai cara ini lain kali, tetapi karena belum menyiapkan token API sebelumnya, saya hanya bisa menunggu
    Untungnya sekarang sudah pulih dan kembali online
  • Saya menanganinya lewat Terraform provider, tetapi metode ini berguna bagi orang yang tidak bisa mengakses dashboard
  • Tips yang bagus. Sebagai catatan, pada curl, request GET adalah default sehingga -X GET tidak diperlukan
    Jika memakai opsi -d, otomatis menjadi POST, dan untuk PATCH memang benar memakai -X PATCH
  • Menyalakan Cloudflare WARP membuat beberapa situs kembali berfungsi. Mungkin 1.1.1.1 juga memberi efek serupa
    Namun, bahkan setelah ditunnel, beberapa situs masih tetap down sebagian

• Menurut CTO Cloudflare, bug potensial pada sistem pemblokiran bot mengamuk setelah perubahan konfigurasi dan menyebabkan gangguan di seluruh jaringan
  Ia menjelaskan di sumber bahwa ini bukan serangan, melainkan masalah internal

  • Mengejutkan bahwa perusahaan besar masih tidak melakukan rollout perubahan konfigurasi secara bertahap
    Kode maupun konfigurasi sama-sama data, tetapi pola merilis ke seluruh dunia sekaligus lalu memicu outage besar terus berulang
  • Saya berharap informasi kunci seperti ini muncul di bagian atas komentar. Sulit menemukannya di antara komentar spekulasi soal serangan siber
  • Hanya karena satu perubahan konfigurasi, saham CF turun 4%. Saya penasaran dengan dampak ekonomi gangguan seperti ini terhadap seluruh industri

• Seorang rekan kerja tiba-tiba berlari menghampiri dan bilang bahwa tepat setelah ia mengubah konfigurasi Cloudflare, situsnya down, jadi ia panik mengira dirinya yang merusakkannya
  Katanya ia lega setelah melihat postingan ini

  • Saya bercanda, “Lebih parah dari itu, kamu yang menjatuhkan seluruh Cloudflare”
  • Tapi benarkah bukan? Dulu pernah ada outage besar Fastly, jadi rasa curiga masih ada
  • Saya penasaran apakah ada kata yang pas untuk rasa lega yang aneh saat tahu bukan seseorang yang melakukan kesalahan
  • Mungkin saja rekan kerja itu pegawai Cloudflare
  • Saya juga menerima puluhan pesan dari klien bahwa situs tidak bisa diakses, dan karena kemarin saya sempat mengubah konfigurasi, saya berkeringat dingin
    Saat melihat pesan “Cloudflare down”, saya benar-benar merasa lega

• Setelah dicek dari Belanda, hampir semua layanan sedang down
  Dashboard Cloudflare juga tidak bisa diakses, begitu pula dashboard Betterstack
  Ironisnya, halaman status tetap hidup sehingga malah tidak bisa dipakai untuk memberi tahu pelanggan

  • Saya mengalami hal yang sama. Alasan hanya HN yang tetap normal adalah karena tidak memakai Cloudflare
    Saya pernah menulis postingan blog yang intinya “jangan taruh layanan di belakang Cloudflare kalau tidak perlu”
  • Setiap tahun kita sadar betapa berbahayanya terlalu bergantung pada AWS atau Cloudflare, tetapi mencari penggantinya tidak mudah
    Meski begitu, saat outage sebesar ini terjadi, pelanggan ternyata menunjukkan pengertian yang tak terduga
  • Dashboard Cloudflare sebenarnya tidak benar-benar mati total; kalau cukup gigih mencoba, Anda bisa mematikan proxy
    Butuh beberapa menit, tetapi saya berhasil melepaskan hcker.news dari CF
  • Melihat situasi seperti ini, sepertinya ada peluang bisnis untuk membuat layanan yang meng-host halaman status di VPS lokal
  • Di side project saya, Total Real Returns,
    saya menaruh widget uptime real-time yang terhubung ke halaman status eksternal di bagian bawah
    Lihat status SVG dan
    halaman status eksternal

• Ada kepuasan tersendiri saat melihat layanan self-hosted saya tetap berjalan normal ketika Cloudflare atau AWS berhenti
  Dibanding availability 99.999% mereka, saat ini sistem saya justru lebih stabil

  • Situs pribadi saya yang seadanya juga tetap hidup saat AWS, Azure, dan Cloudflare outage
    Sekarang saya jadi berpikir untuk memasang uptime tracker
  • Situs self-hosted saya justru down karena proxy Cloudflare. Rasanya ironis
  • Perusahaan tradisional sedang mengalami situasi di mana sistem seperti Oracle dan SAP tetap baik-baik saja, tetapi hanya layanan baru berbasis cloud yang berhenti
    Ini pelajaran yang harus dipahami perusahaan SaaS baru
  • Banyak yang bertanya soal bagaimana menangani DNS. Saya sendiri hosting di Raspberry Pi, dan kebetulan baru saja memindahkan DNS ke Cloudflare
    Jadi lucu sekaligus agak memuaskan melihat situs kecil saya ikut down

• Belakangan ini terasa seperti gangguan infrastruktur berskala besar meningkat tajam. AWS dan Cloudflare sama-sama jauh di bawah SLA

  • Ini bertepatan dengan saat perusahaan besar melakukan PHK massal lalu bilang akan menggantinya dengan AI
  • Dari outage seperti ini, saya sadar bahwa jumlah angka 9 pada SLA itu tidak banyak artinya
    Itu bukan angka uptime nyata, melainkan sekadar angka yang didefinisikan sepihak oleh perusahaan
  • Ada yang menyebutnya “vibe code theory”. Semacam teori bercanda bahwa makin banyak kode yang ditulis berdasarkan feeling, makin banyak pula bug dan outage
  • Ada juga analisis bahwa penyebabnya adalah budaya deploy terburu-buru karena bertemunya periode larangan deploy akhir tahun dan tekanan target Q4
  • Atau mungkin ini serangan siber tingkat negara menurut pandangan yang lebih bernuansa teori konspirasi

• Saat Cloudflare atau AWS berhenti, masalah sentralisasi yang membuat separuh web ikut berhenti menjadi sangat serius

  • Pengguna pun tidak terlalu peduli. Karena dianggap sekadar “internet sedang bermasalah”, layanan individual bisa lepas dari tanggung jawab
    Itulah alasan struktur seperti ini tidak berubah
  • Dalam pertahanan DDoS, skala ekonomi berlaku. Semakin banyak pelanggan, semakin besar bandwidth dan semakin kuat pertahanannya
    CDN kecil sulit bersaing, dan akhirnya terbentuk struktur monopoli alami
    Cloudflare menyediakan paket gratis sebagai strategi untuk memanfaatkan efek jaringan ini
  • Yang lebih mengkhawatirkan daripada single point of failure adalah bahwa sentralisasi seperti ini bisa mendistorsi standar web dan masa depan self-hosting
    Selain itu, tempat seperti ini juga berpotensi menjadi target terpusat bagi sensor pemerintah
  • Let's Encrypt juga punya potensi risiko.
    Dua pertiga web bergantung padanya, masa berlaku sertifikat makin pendek, dan jika terjadi peretasan atau outage, seluruh web bisa lumpuh
    Sekarang memang organisasi yang baik, tetapi jangan lupa Google di masa lalu juga dulu dipandang begitu
  • Setelah demam AWS, para developer jadi hanya bergantung pada cloud alih-alih dedicated server
    Backup di level software memang banyak, tetapi pengetahuan umum soal multi-hosting di level infrastruktur justru menghilang

• Ironisnya, DownDetector juga memakai Cloudflare Turnstile sehingga ikut down

  • Laporan outage AWS juga melonjak, tetapi kemungkinan besar itu false positive
  • Saya juga melihat gejala itu

• Pesan visual permintaan maaf Cloudflare berupa “Your browser: Working / Host: Working / Cloudflare: Error” terasa mengesankan

  • Ini pertama kalinya saya melihat layar seperti itu. Hanya saja dalam kasus saya, “Host”-nya adalah Cloudflare Pages, jadi maknanya terasa ambigu
  • Agak lucu bahwa saat mengklik “Cloudflare”, penjelasannya tetap mengarah pada masalah di server pelanggan
  • Saya suka karena pesannya jujur, tetapi reaksi pengguna tetap cuma “tolong perbaiki Wi-Fi”-nya
  • Meski begitu, setidaknya situasinya jadi jelas dan bisa ditangani. Jika perlu, proxy bisa dinonaktifkan untuk meminimalkan dampak layanan
  • Saya juga sempat membongkar log selama satu jam sebelum sadar bahwa ini bukan masalah di server saya

• Situs yang memakai Cloudflare Challenge (“I’m not a robot”) juga berhenti dengan error HTTP 500
  Muncul pesan yang meminta untuk membuka blokir challenges.cloudflare.com

  • Akhir-akhir ini kualitas penanganan error terlalu buruk. Perusahaan menghindari tanggung jawab dengan menyalahkan pengguna, atau hanya menampilkan loading tanpa akhir
    Padahal backend sebenarnya mengembalikan error yang jelas, tetapi disembunyikan oleh frontend
    Baru-baru ini saya bahkan melihat kasus error karena kata sandi terlalu panjang ditampilkan sebagai “email sudah digunakan”
  • Karena outage ini, AI search (GPT5) di chat.bing.com juga ikut berhenti
    Ironisnya, jadinya kita harus membuktikan kepada AI bahwa kita ini manusia
  • Beberapa situs (seperti pinkbike) menampilkan pesan “you have been blocked”
  • Jadi bukan hanya robot, manusia sungguhan juga ikut diblokir /s
  • Sepertinya frontend salah mengira bahwa pengguna memblokir domain tersebut lewat DNS atau extension
    Penyangkalan gaya /s bahwa Cloudflare Captcha tidak mungkin down terasa lucu