Cloudflare Mencatat 13 Gangguan dalam Delapan Hari Bulan Ini: Berapa Harga Sebenarnya dari Bergantung pada Satu Penyedia untuk Website Bisnis Kecil

Halaman status Cloudflare mencatat 13 insiden terpisah dalam delapan hari bulan ini, dari 7 sampai 14 Agustus 2026. Insiden itu menyentuh penyimpanan objek R2, Durable Objects, Workers KV, Workers AI, keamanan email, dan kinerja jaringan di empat benua. Hampir semuanya kecil bila dilihat satu per satu. Namun, rangkaian itu memunculkan pertanyaan yang selalu kembali bagi tim infrastruktur: apa yang terjadi ketika satu perusahaan berada di depan kira-kira seperempat trafik web dan layanannya bermasalah berulang kali dalam satu pekan.

Bagi pemilik toko, klinik, agensi kecil, atau bisnis makanan yang berjualan online, nama seperti Cloudflare, R2, dan Durable Objects mungkin terdengar jauh dari kegiatan sehari-hari. Kenyataannya tidak begitu. Sebagian besar DNS, CDN, dan penyimpanan objek di internet berjalan melalui sedikit penyedia besar. Website bisnis kecil kerap bergantung pada salah satunya tanpa pemilik sadar bahwa pilihan itu pernah dibuat, karena layanan tersebut sudah termasuk dalam paket hosting, page builder, atau susunan teknis bawaan pengembang. Ketika penyedia itu mengalami minggu yang buruk, checkout melambat, foto produk gagal dimuat, atau formulir kontak berhenti mengirim. Pemilik bisnis hanya melihat gejalanya.

Artikel ini membedakan catatan yang benar-benar muncul di halaman status Cloudflare dari pelajaran praktisnya bagi bisnis kecil yang belum pernah membuka halaman status layanan.

🧭 Catatan yang Benar-Benar Muncul di Halaman Status

Cloudflare menerbitkan riwayat insiden publik di cloudflarestatus.com/history. Halaman itu menjadi sumber utama artikel ini. Antara 7 dan 14 Agustus 2026, riwayat tersebut mencatat 13 insiden di luar jadwal pemeliharaan rutin pada data center, menurut rangkuman outlet teknologi Shattered.io yang menelaah riwayat publik yang sama.

Membaca halaman status secara langsung penting karena rangkuman media sering menyederhanakan urutan kejadian. Halaman resmi Cloudflare mencatat setiap insiden dengan stempel waktu, wilayah terdampak, dan status penyelesaian yang diperbarui berkala, bukan ringkasan satu paragraf. Bagi pemilik website yang ingin memverifikasi apakah gangguan yang mereka alami benar terkait insiden tertentu, kebiasaan membuka halaman status resmi dan mencocokkan waktu kejadian jauh lebih dapat diandalkan daripada menebak dari cuitan atau forum.

Rangkaian itu dimulai pada 7 Agustus dengan gangguan ketersediaan penulisan pada sejumlah kecil bucket R2 di wilayah Eastern North America atau ENAM, antara 14:52 dan 17:02 UTC. Pemulihan berlanjut hingga 8 Agustus. Hari itu muncul masalah kedua yang tidak berkaitan, yaitu kinerja jaringan di Istanbul setelah Cloudflare melaporkan kehilangan konektivitas dark fiber di wilayah tersebut. Tiga hari berikutnya lebih tenang. Lalu, sejak 11 Agustus, frekuensinya naik lagi: kesalahan konektivitas di London, pemeliharaan penyimpanan terjadwal, dan pada 12 Agustus gangguan keamanan email berstatus major yang berkaitan dengan daftar Spamhaus dan memengaruhi pengiriman email keluar bagi sebagian pelanggan.

Tanggal 13 dan 14 Agustus menjadi hari tersibuk dengan masing-masing empat insiden. Pada 13 Agustus, pelanggan melihat kenaikan error 503 ketika mengubah Magic Transit lewat dashboard atau API, error lebih tinggi pada permintaan Workers KV, kegagalan autentikasi berkala di MCP Server Portal, dan error Workers AI untuk model tertentu. Pada 14 Agustus, halaman status mencatat penurunan ketersediaan Durable Objects dan Cloudflare Workflows yang berpusat pada kolokasi Miami, kemacetan jaringan di Amerika Serikat bagian timur, error HTTP 5xx di Kuwait, Bangkok, Jakarta, dan Dammam, serta masalah kinerja jaringan di Queretaro, Meksiko.

Halaman status Cloudflare mengonfirmasi salah satu insiden terpendek itu. Insiden Durable Objects dan Workflows dibuka pada 14 Agustus pukul 15:27 EDT saat tim menyatakan sedang menangani penurunan ketersediaan, lalu ditutup 38 menit kemudian.

Insiden ini menjadi penanda yang berguna untuk membaca keseluruhan cerita: cepat ditemukan, cepat diperbaiki, dan diberi status minor. Sebagian besar dari 13 insiden mengikuti pola tersebut. Gangguan penyimpanan R2 pada 7 Agustus berbeda.

🗄️ Mengapa Gangguan R2 Paling Banyak Diperhatikan

Gangguan penyimpanan objek lebih berisiko daripada masalah dashboard karena layanan itu memegang berkas yang dibutuhkan website dan aplikasi untuk bekerja: foto produk, cadangan, dokumen unggahan, serta aset yang dihasilkan sistem. Pembaruan status Cloudflare menyebut dampak 7 Agustus sebagai kegagalan penulisan pada sejumlah kecil bucket di ENAM. Perusahaan menyatakan telah mengidentifikasi penyebabnya pada 22:54 UTC hari itu dan sedang memulihkan akses penuh. Sebagian besar bucket pulih dalam kira-kira satu hari. Namun, laporan Shattered.io menyebut sebagian objek yang diunggah lewat multipart upload pada jendela awal membutuhkan waktu lebih lama untuk muncul kembali.

Setidaknya satu pelanggan melaporkan di forum komunitas Cloudflare bahwa data dalam bucket R2 belum kembali setelah insiden, dengan kira-kira 67GB masih belum pulih beberapa hari kemudian, menurut Shattered.io. Cloudflare belum menerbitkan postmortem resmi yang mengonfirmasi kehilangan data permanen pada kasus khusus itu, sementara pembaruan publiknya menandai insiden sebagai selesai. Jarak antara halaman status yang mengatakan selesai dan pelanggan yang masih tidak menemukan berkasnya tidak hanya terjadi di Cloudflare. Ini adalah alasan tim teknis memperlakukan penyimpanan objek seperti ketergantungan pada satu vendor lain: layak memiliki cadangan mandiri, bukan hanya mengandalkan pemberitahuan bahwa layanan sudah pulih.

⚙️ Durable Objects dan Risiko Menyatukan Banyak Layanan

Insiden terakhir pada periode itu, penurunan ketersediaan Durable Objects dan Workflows, selesai pada hari yang sama dan menjadi yang tercepat dari tiga belas insiden. Durable Objects menopang aplikasi stateful di Cloudflare Workers, misalnya backend chat atau logika koordinasi aplikasi. Workflows adalah layanan Cloudflare untuk tugas latar belakang yang berjalan lama dan dapat dicoba ulang. Penurunan ketersediaan pada salah satunya bukan sekadar membuat halaman lambat. Ia dapat menahan logika bisnis yang diasumsikan pengembang akan selesai di latar belakang, seperti langkah konfirmasi pembayaran atau pembaruan status pesanan.

Cloudflare memberi status minor dan menutup insiden itu dalam 38 menit. Ini sangat berbeda dengan pemulihan R2 yang berlangsung berhari-hari sepekan sebelumnya. Perbedaan itu penting ketika pemilik website membaca risiko dari halaman status: tidak setiap insiden memiliki bobot yang sama. Menyamakan gangguan 38 menit dengan pemulihan penyimpanan multi-hari mengaburkan keputusan tentang bagian mana yang lebih dahulu membutuhkan cadangan.

🌐 Risiko Konsentrasi di Balik Berita Ini

Skala Cloudflare membuat rangkaian insiden yang sebagian besar minor tetap menjadi berita. W3Techs, yang mengukur penggunaan reverse proxy di web, mencatat Cloudflare digunakan oleh kira-kira seperempat seluruh website yang diukurnya pada Agustus 2026, dan oleh lebih dari empat dari lima website yang penyedia reverse proxy-nya dapat diidentifikasi. Cloudflare sendiri menyatakan jaringannya menangani lebih dari seperlima trafik internet global yang terukur.

Skala itu berarti gangguan jaringan regional di Queretaro atau kenaikan error di Workers KV tidak berhenti di dashboard Cloudflare. Dampaknya dapat tampak sebagai checkout lambat, login gagal, atau panggilan API yang rusak di ribuan bisnis yang tidak pernah merasa secara langsung memilih satu vendor tersebut. Mereka hanya memakai CDN, atau penyedia hostingnya yang memakainya.

Inilah kompromi struktural komputasi edge pada skala Cloudflare. Menyatukan DNS, CDN, web application firewall, komputasi serverless, dan penyimpanan objek pada satu penyedia mengurangi pekerjaan operasional bisnis yang sebelumnya harus merangkai lima layanan berbeda. Sebaliknya, satu insiden dapat menyentuh resolusi DNS, pengiriman halaman, autentikasi, dan logika aplikasi bersamaan, bukan gagal secara terpisah. Ketika halaman status mencatat empat insiden pada 13 Agustus dan empat lagi pada 14 Agustus, itu berarti beberapa subsistem berbeda mengalami masalah pada hari yang sama, bukan satu penyebab tunggal.

📊 Perbandingannya dengan Hari Terburuk Cloudflare

Rangkaian Agustus 2026 bukan gangguan R2 pertama bagi Cloudflare dan bukan pula outage terburuk perusahaan. Pada 21 Maret 2025, outage R2 sebelumnya ditelusuri ke kesalahan rotasi kredensial saat deployment rutin. Kredensial penyimpanan baru masuk ke lingkungan development, bukan production. Ketika kredensial lama dihapus dalam proses rotasi, R2 production tidak lagi memiliki autentikasi yang valid. Postmortem Cloudflare sendiri menyebut insiden ini berlangsung satu jam tujuh menit, dengan semua operasi tulis dan kira-kira sepertiga operasi baca gagal. Perbaikan yang diumumkan Cloudflare adalah kewajiban persetujuan sedikitnya dua engineer untuk perubahan kredensial berdampak tinggi.

Peristiwa yang jauh lebih besar terjadi pada 18 November 2025. Menurut postmortem resmi Cloudflare, perubahan izin database rutin memicu kueri yang membuat berkas fitur bot management berisi data duplikat. Ukurannya menjadi dua kali lipat dan melewati batas keras dalam perangkat lunak proxy inti. Berkas terlalu besar itu membuat layanan proxy berhenti. Trafik inti mulai mengembalikan error pukul 11:20 UTC, sebagian besar layanan pulih sekitar 14:30 UTC, dan penyelesaian penuh dicatat pukul 17:06 UTC. Daftar layanan terdampak mencakup dashboard Cloudflare, widget verifikasi Turnstile, Workers KV, dan Access. Sebagian pelanggan bahkan tidak dapat membuka akun mereka sendiri di tengah insiden.

Dibandingkan sejarah itu, tiga belas insiden yang sebagian besar minor dalam delapan hari terlihat lebih ringan. Penilaian Cloudflare mendukungnya: dua belas dari tiga belas diberi label minor, dan hanya gangguan email 12 Agustus yang berstatus major. Meski begitu, rangkaian itu mengingatkan bahwa kondisi yang memungkinkan outage November 2025, jaringan yang sangat rapat sehingga satu perubahan buruk dapat menjalar ke banyak produk, tidak otomatis hilang setelah perbaikan postmortem diterapkan.

💰 Pertumbuhan Cepat Ketika Insiden Bertumpuk

Rangkaian insiden muncul pada saat bisnis Cloudflare justru tumbuh. Hasil kuartal kedua 2026 yang diumumkan 6 Agustus mencatat pendapatan 696,1 juta dolar AS, naik 36 persen dibanding setahun sebelumnya. Laba per saham terdilusi non-GAAP naik menjadi 0,29 dolar AS dari 0,21 dolar AS. Cloudflare juga melaporkan tambahan 986 pelanggan besar, yaitu pelanggan dengan belanja tahunan di atas 100.000 dolar AS, dalam dua belas bulan sebelumnya. Pertumbuhan itu tidak menjelaskan atau membenarkan delapan hari insiden sebulan kemudian. Namun, data itu menunjukkan insiden bukan tanda perusahaan berhenti tumbuh. Ini adalah jaringan yang semakin besar dan semakin rumit, bekerja di bawah beban yang juga semakin besar.

🌏 Mengapa Ini Relevan Meski Bisnis Anda Tidak Mengenal Cloudflare

UMKM Indonesia jarang memilih CDN atau penyedia penyimpanan objek berdasarkan nama. Pemilik toko membeli paket hosting, menyerahkan akses WordPress kepada pengembang, atau meluncurkan situs lewat page builder. Penyedia yang berada di depan susunan tersebut dipilih sekali, lalu mudah terlupakan. Ini bukan kesalahan pemilik usaha. Orang yang menjalankan toko roti atau klinik tidak seharusnya wajib menjadi engineer jaringan agar websitenya tetap aktif. Akan tetapi, insiden pada halaman status penyedia juga jarang langsung sampai kepada pemilik bisnis. Yang sampai biasanya pesan pelanggan yang bertanya mengapa formulir pesanan online tidak bekerja, atau booking yang hilang karena halaman membutuhkan sebelas detik untuk termuat.

Sebaran empat benua dalam rangkaian ini penting karena alasan tersebut. Insiden 14 Agustus menyentuh Kuwait, Bangkok, Jakarta, dan Dammam, selain Amerika Serikat bagian timur dan Queretaro. Bisnis di Jakarta yang memakai stack hosting dengan rute ke lokasi edge terdampak tidak harus menjadi pelanggan Cloudflare atas nama sendiri untuk merasakan perlambatan. Gangguan jaringan regional pada edge bersama dapat membuat pengunjung di satu kota menerima halaman yang lambat, sementara situs yang sama terlihat normal di kota lain. Karena itu, satu ulasan pelanggan yang mengeluh situs lambat tidak selalu berarti seluruh situs sedang mati.

🧮 Cloudflare Dibanding Penyedia Infrastruktur Lain

Cloudflare bukan satu-satunya penyedia besar yang mengalami periode tidak mulus. Rangkuman pelacakan outage yang dikutip Shattered.io menempatkan rata-rata uptime terlapor AWS pada 2023 sampai 2025 sekitar 99,95 persen dengan pemulihan rata-rata 2,8 jam. Microsoft Azure disebut memiliki rata-rata uptime sedikit lebih tinggi, sekitar 99,97 persen, tetapi waktu pemulihan rata-rata lebih lama, sekitar 4,2 jam. Wilayah us-east-1 AWS sendiri mengalami outage 28 jam yang menjadi berita besar dalam periode yang sama. Google Cloud secara umum mencatat lebih sedikit outage besar yang dipublikasikan dibanding AWS selama beberapa tahun terakhir.

Cloudflare tidak menerbitkan satu angka uptime agregat seperti banyak penyedia cloud berbasis SLA. Halaman statusnya juga mencatat insiden tingkat layanan secara lebih rinci daripada banyak pesaing, sehingga jumlah insiden publiknya dapat terlihat lebih tinggi dibanding penyedia lain yang mengalami kuartal sama bergelombangnya tetapi memiliki halaman status lebih sunyi. Perbandingan empat penyedia itu tetap mengarah ke satu pelajaran yang sama: ketergantungan pada satu wilayah dan satu vendor adalah benang merah dalam banyak cerita outage besar dua tahun terakhir, terlepas dari logo pada postmortem.

🔍 Membaca Halaman Status Tanpa Bereaksi Berlebihan

Halaman status tidak ditulis untuk pemilik bisnis kecil, dan celah itu sering menjadi sumber kebingungan saat outage terjadi. Cloudflare memberi label minor, major, atau critical pada setiap insiden. Label itu mencerminkan cakupan yang diukur Cloudflare sendiri, bukan seberapa parah dampaknya bagi satu pelanggan tertentu. Label minor pada error Workers KV misalnya tetap bisa berarti gangguan total bagi satu aplikasi kecil yang sangat bergantung pada fitur itu, meski mayoritas pelanggan Cloudflare lain tidak merasakan apa pun. Sebaliknya juga terjadi: label major pada gangguan keamanan email seperti daftar Spamhaus tanggal 12 Agustus mungkin nyaris tidak berdampak bagi bisnis yang hanya menjalankan website biasa, tetapi sangat mengganggu bisnis yang bergantung pada email transaksional.

Kebiasaan praktis yang layak dibangun adalah memeriksa halaman status untuk layanan spesifik yang dipakai situs Anda, bukan halaman secara keseluruhan. Jika pengembang mengatakan gambar, DNS, atau backend situs berjalan di Cloudflare, itu baru titik awal percakapan, bukan akhirnya. Tanyakan produk spesifik apa yang dipakai: R2 untuk penyimpanan, Workers untuk logika backend, atau sekadar lapisan CDN dan DNS yang dipakai kebanyakan situs secara default. Situs yang hanya memakai CDN dan DNS jauh lebih kecil risikonya terhadap insiden Durable Objects atau Workers AI dibanding situs yang dibangun penuh sebagai aplikasi serverless di platform yang sama.

🇮🇩 Konteksnya untuk Bisnis di Indonesia

UMKM Indonesia berada dalam gambaran ini dengan cara yang khas. Banyak penyedia hosting lokal, page builder, bahkan sebagian integrasi bank dan payment gateway merutekan sebagian trafiknya melalui Cloudflare atau jaringan edge global sejenis, sering kali tanpa mencantumkannya di halaman harga. Pemilik bisnis di Surabaya atau Medan yang memeriksa apakah situsnya terdampak saat jendela insiden sebaiknya melihat dulu apakah situs lambat bagi pengunjung di satu kota tertentu sementara normal di kota lain, karena pola itu menunjukkan masalah edge regional, bukan masalah pada kode situs itu sendiri.

Pengembang dan agensi lokal yang membangun di WordPress, WooCommerce, atau storefront headless sering menambahkan Cloudflare sebagai lapisan gratis untuk proteksi DDoS dasar dan caching, pilihan yang wajar untuk kebanyakan situs kecil. Risikonya bukan pada penggunaan Cloudflare itu sendiri. Risikonya adalah tidak pernah bertanya layanan apa saja yang berjalan lewat akun yang sama: hanya DNS, atau DNS ditambah optimasi gambar ditambah web application firewall, dan semakin sering, penyimpanan objek untuk foto produk serta konten video. Setiap layanan tambahan menambah kenyamanan sekaligus menambah satu hal lagi yang bisa ikut terdampak pada jendela insiden berikutnya, siapa pun penyedianya.

🏪 Langkah Nyata untuk Website Bisnis Kecil

Kebanyakan pemilik bisnis kecil tidak akan rutin membaca halaman status, dan mereka tidak perlu melakukannya untuk menjalankan website. Mereka membutuhkan respons singkat dan praktis untuk minggu seperti ini. Empat pemeriksaan berikut mencakup sebagian besar kebutuhan.

1. Kenali layanan yang berada di belakang website. Website builder, paket hosting, atau susunan pengembang dapat merutekan DNS, CDN, pengiriman gambar, bahkan logika backend melalui penyedia yang sama tanpa menuliskan namanya di tagihan. Tanyakan secara langsung: perusahaan mana yang menangani DNS, CDN, dan penyimpanan berkas kami, dan apakah ketiganya sama.
2. Bedakan gangguan umum dengan masalah pada konfigurasi sendiri. Saat outage, periksa halaman status publik dan situs seperti Downdetector sebelum menyimpulkan masalah hanya terjadi pada bisnis Anda. Jika status penyedia sudah resolved tetapi situs Anda tetap bermasalah, laporkan jarak itu kepada pengembang, jangan hanya menunggu.
3. Simpan cadangan mandiri untuk data yang ada pada satu penyedia. Foto produk, ekspor data pelanggan, dan backup situs perlu memiliki salinan yang tidak hanya hidup dalam layanan penyimpanan objek yang sama dengan situs. Laporan pelanggan R2 tentang 67GB yang masih hilang beberapa hari setelah status resolved adalah contoh tepat risiko yang dilindungi oleh backup mandiri.
4. Tanyakan apa yang terjadi saat penyedia mengalami gangguan, bukan hanya setelahnya. Website yang langsung blank saat CDN bermasalah memiliki risiko berbeda dibanding website yang tetap menampilkan versi cache homepage ketika checkout sementara tidak tersedia. Perbedaan itu umumnya merupakan pilihan konfigurasi. Tanyakan kepada pengembang sebelum insiden berikutnya, bukan ketika pelanggan sudah tidak dapat mengakses situs.

Langkah ini tidak berarti bisnis harus meninggalkan penyedia besar atau membangun tumpukan lima vendor dalam semalam. Skala Cloudflare juga membuat layanannya cepat, terjangkau, dan aman bagi jutaan situs kecil yang tidak mungkin membangun infrastruktur setara sendiri. Tujuan praktisnya lebih kecil: pahami ketergantungan, simpan satu backup di luar ketergantungan itu, dan gunakan halaman status sebagai pemberhentian pertama saat terjadi gangguan.

Biaya nyata dari mengabaikan langkah-langkah ini biasanya baru terasa pada hari yang buruk, bukan hari biasa. Toko online kecil yang kehilangan enam jam trafik saat jam sibuk mungkin kehilangan penjualan senilai jutaan rupiah, jumlah yang cukup untuk menutup biaya satu layanan monitoring uptime pihak ketiga selama setahun penuh. Klinik yang formulir booking-nya mati selama satu pagi kehilangan pasien yang akhirnya mencari alternatif lewat pencarian Google biasa. Risiko ini tidak butuh solusi mahal. Sebagian besar penyedia monitoring uptime menawarkan paket gratis yang cukup untuk mengirim notifikasi WhatsApp atau email begitu situs tidak merespons, dan itu saja sudah memangkas waktu deteksi dari berjam-jam menjadi beberapa menit.

Lakukan latihan lima menit agar rencana ini nyata. Buka akun registrar domain dan catat ke mana nameserver DNS mengarah. Tanyakan kepada orang yang mengelola website lokasi backup harian atau mingguan serta apakah Anda dapat mengunduhnya tanpa menunggu penyedia yang sama aktif kembali. Uji formulir kontak dari ponsel dengan data seluler, lalu catat siapa yang menerima pesan dan di mana kiriman disimpan. Terakhir, tulis nama satu orang yang dapat dihubungi saat situs tidak tersedia serta satu saluran alternatif, misalnya WhatsApp Business, tempat pelanggan masih dapat memesan. Detail ini tampak biasa sampai pelanggan tidak dapat menghubungi bisnis. Pada hari itu, detail tersebut menentukan apakah gangguan hanya menghabiskan beberapa menit atau satu hari penjualan.

Sumber: Cloudflare Status History (cloudflarestatus.com/history); Cloudflare Status Dashboard, insiden Durable Objects dan Cloudflare Workflows availability drop, 14 Agustus 2026; Shattered.io, "Cloudflare Logs 13 Outages in 8 Days as R2 Falters," diperbarui 16 Agustus 2026; W3Techs, statistik penggunaan Cloudflare, Agustus 2026; Cloudflare, Second Quarter 2026 Financial Results, 6 Agustus 2026; Cloudflare Blog, "Cloudflare outage on November 18, 2025."