Dua Puluh Insiden dalam Delapan Hari: Arti Rentetan Cloudflare untuk Stack Anda

Dua Puluh Insiden dalam Delapan Hari: Arti Rentetan Cloudflare untuk Stack Anda

Antara 7 dan 14 Agustus 2026, status page resmi Cloudflare mencatat dua puluh insiden terpisah. R2 object storage, Workers KV, MCP Server Portal, Workers AI, Magic Transit, Durable Objects, dan Workflows. Plus gangguan jaringan regional di Querétaro, sebagian Timur Tengah dan Asia Tenggara, Eastern US, London, dan Fuzhou/Foshan.

Sebagian besar tercatat Minor atau tanpa klasifikasi. Kecuali satu: gangguan Email Security dan Spamhaus dengan severity Major pada 12 Agustus (Cloudflare status API).

Tak satu pun jadi headline sebesar outage global Cloudflare November 2025 (postmortem Cloudflare). Bukan karena perusahaannya jadi lebih ceroboh. Beginilah kesehariannya kalau yang dijalankan seperempat internet — sebagian besar insiden selesai sebelum disadari pengguna di luar akun yang terdampak.

Artikel ini bukan tentang siklus beritanya. Ini tentang apa yang seharusnya berubah dalam cara Anda merencanakan infrastruktur setelah rentetan delapan hari seperti ini.

Satu insiden, ditelusuri lebih dekat

Pada 7 Agustus, penulisan ke sejumlah kecil bucket R2 di region ENAM mulai gagal pukul 14:52 UTC. Pukul 22:54 malam itu, Cloudflare bilang sudah menemukan penyebabnya dan menghentikan kerusakan lebih lanjut. Namun status update masih berbunyi "continuing to work to restore normal availability" pada 23:05.

Pemulihan penuh baru dikonfirmasi pukul 02:35 UTC tanggal 9 Agustus, lebih dari sehari setelah penulisan pertama kali gagal. Sejumlah pelanggan melaporkan di forum komunitas Cloudflare bahwa sebagian data mereka, puluhan gigabyte di setidaknya satu kasus, tidak pernah kembali (komunitas Cloudflare).

Itu insiden yang baru terjadi. Bandingkan dengan insiden yang lebih lama, karena insiden lama itu menjelaskan mode kegagalan yang tidak ada hubungannya dengan nasib sial.

Pada Maret 2025, R2 down 67 menit gara-gara pekerjaan yang seharusnya rutin saja: rotasi kredensial storage. Engineer yang melakukan rotasi menjalankan perintah Wrangler tanpa flag --env production. Kredensial baru ter-deploy ke Worker development default, bukan ke production.

Ketika kredensial lama kemudian dihapus — langkah normal berikutnya dalam rotasi apa pun — production R2 kehilangan satu-satunya autentikasi yang valid. Penulisan gagal 100%.

Pembacaan gagal sekitar 35%. Upload Image, upload Stream, dan insert Vectorize semuanya gagal total (postmortem Cloudflare).

Bukan karena eksploitasi, bukan kerusakan hardware, bukan mentok kapasitas. Satu flag command-line yang terlewat, dijalankan manual, pada perubahan yang menyentuh semua pelanggan di storage layer itu sekaligus.

Pelajarannya, diterjemahkan ke stack Anda

Perbaikan Cloudflare bukan "lebih hati-hati." Perbaikannya struktural: mengganti rotasi kredensial manual lewat CLI dengan tooling otomatis wajib yang mengunci konfigurasi environment-nya sendiri. Cloudflare juga menambahkan review dua orang untuk perubahan kredensial, dan health check otomatis yang memastikan kredensial baru sudah tersebar sebelum yang lama dihapus (postmortem Cloudflare).

Itu pola yang layak dicontoh, bukan insidennya. Satu langkah manual bisa merobohkan production di salah satu tim infrastruktur paling kaya resource di dunia. Langkah manual serupa di infrastruktur Anda membawa risiko yang sama — skalanya saja yang lebih kecil.

Outage vendor otomatis jadi outage Anda, begitu produk bergantung pada uptime mereka. Rotasi kredensial manual, skrip deploy yang dijalankan orang, kebiasaan "ada yang SSH masuk lalu membereskannya" — itu mode kegagalan yang sama, hanya berganti logo. Perbaiki prosesnya, bukan orang yang kebetulan sedang piket.

Bundling melipatgandakan blast radius

Bayangkan sebuah rumah menaruh listrik, air, gas, dan internet lewat satu penyedia yang sama. Sekali penyedia itu bermasalah, empat layanan mati sekaligus — bukan satu. Begitu juga sebuah stack teknologi. Kalau CDN, DNS, object storage, dan compute semuanya di satu vendor, seminggu buruk bagi vendor itu jadi seminggu buruk untuk seluruh stack sekaligus.

Kalau empat fungsi itu disebar ke empat vendor, insiden di salah satunya cuma mengganggu satu layer. Kalau keempatnya ditumpuk di satu vendor, satu insiden menghantam seluruh stack sekaligus — tanpa satu pun jalan memutar tersisa.

Kenapa ini sekarang rutin, bukan pengecualian

Cloudflare melayani 24,8% dari seluruh situs yang dilacak W3Techs, dan 84,4% dari situs yang memakai reverse proxy yang bisa diidentifikasi. Jarak dari kompetitor terdekatnya jauh — "pilih CDN mana" nyaris bukan pilihan nyata bagi sebagian besar pasar (W3Techs). Di skala itu, dua puluh insiden dalam delapan hari bukan bulan yang buruk. Itu output normal dari surface area sebesar itu — dan akan tetap begitu, siapa pun vendor yang menempati posisi itu berikutnya.

Yang perlu dicek dalam infra review SME

1. Petakan setiap layer. DNS, CDN, object storage, compute — hitung berapa yang bermuara ke vendor yang sama. Tuliskan angkanya; kebanyakan pemilik bisnis belum pernah menghitungnya.
2. Cek bagaimana kredensial sebenarnya dirotasi. Perintah CLI yang diketik satu orang dari hafalan — persis pola yang menyebabkan outage Maret 2025. Kalau prosesnya seperti itu, tooling wajib dan reviewer kedua menutup celah itu dengan murah.
3. Pastikan ada rencana degraded-mode tertulis — fallback dari cache, mode read-only, jalur DNS alternatif — untuk saat status page menyala merah. Bukan rencana mencegah outage, tapi rencana untuk apa yang dilakukan bisnis selagi outage berlangsung.

Single point of failure jarang kelihatan sebelum hari ia benar-benar bikin masalah. Tahu ada insiden sedang berlangsung sebelum pelanggan yang lapor duluan — itu saja sudah separuh pekerjaan.

Sinyal yang sebenarnya

Dua puluh insiden dalam delapan hari tidak pernah jadi trending. Outage global satu hari dapat postmortem, siklus berita, dan seminggu penuh orang ramai-ramai mengecek ulang redundansinya. Rentetan insiden severity Minor tidak dapat semua itu — dibiarkan lewat begitu saja, sampai suatu minggu akun Anda sendiri kebetulan masuk blast radius-nya.

Siapkan diri untuk frekuensinya, bukan untuk insiden yang jadi headline. Frekuensilah yang sebenarnya menentukan risiko bisnis Anda.