Cloudflare memperkenalkan Spend Management, fitur beta yang memungkinkan pelanggan pay-as-you-go menetapkan batas pengeluaran untuk Workers dan Durable Objects. Pengaturan ini dirancang untuk menghadapi masalah yang berbeda dari sekadar notifikasi: ketika pemakaian melewati ambang yang ditentukan, Cloudflare dapat menghentikan operasi yang menghasilkan biaya, bukan hanya mengirim email peringatan.
Fitur tersebut diumumkan Cloudflare pada 13 November 2026. Untuk tahap awal, Spend Management tersedia bagi pelanggan Pay-as-you-go dan mencakup Workers serta Durable Objects. Pengguna dapat mengaturnya lewat dashboard Cloudflare, cf CLI, atau REST API. Di dashboard, pengaturan berada di Account Billing > Spend limits. Setiap produk memiliki kebijakan pengeluaran sendiri, sehingga batas Workers tidak otomatis membatasi Durable Objects atau layanan Cloudflare lain.
Ada dua pilihan yang perlu dibedakan. Pelanggan dapat memasang email alert agar tetap menerima peringatan tanpa menghentikan aplikasi. Mereka juga dapat memilih spending limit dengan tindakan usage block. Dalam mode kedua, Cloudflare menerapkan kebijakan pemblokiran saat biaya tercatat mencapai batas. Pengguna bisa mengatur nilai ambang, alamat penerima notifikasi, dan beberapa titik peringatan sebelum batas akhir.
Pada Workers, biaya yang dihitung mencakup request dan waktu CPU setelah jatah pemakaian yang sudah termasuk dalam paket. Batas ini berlaku untuk seluruh akun, bukan satu Worker atau satu lingkungan. Artinya, pengujian yang boros dapat menghabiskan batas bersama dan ikut mengganggu Worker produksi di akun yang sama. Batas tersebut juga tidak mencakup biaya langganan Workers Paid atau pemakaian produk lain seperti Workers AI, Workers KV, R2, dan Durable Objects.
Ketika batas Workers berlaku, invokasi baru dapat ditolak. Ini mencakup request HTTP masuk, Cron Triggers, konsumen Queue, Email Workers, serta panggilan dari Worker atau Durable Object lain. Dokumentasi Cloudflare menyebut pengunjung dapat menerima error 1103, meski kode tersebut juga punya penyebab lain. Aset statis yang dilayani tanpa menjalankan kode Worker tetap dapat tersedia, sedangkan route yang memerlukan Worker bisa gagal.
Durable Objects mempunyai perhitungan terpisah. Batasnya mencakup request dan durasi, pembacaan serta penulisan baris SQLite, dan operasi baca, tulis, atau hapus pada penyimpanan key-value. Data yang sudah tersimpan dan biaya langganan Workers Paid tidak masuk dalam batas itu. Setelah kebijakan aktif, request baru melalui stub Durable Object, query SQL, pertumbuhan SQLite, dan alarm baru dapat ditolak. Alarm yang tertahan masih bisa dipulihkan setelah layanan kembali, tetapi alarm yang tertunda lebih dari tujuh hari dapat dihapus.
Konsekuensinya, Spend Management bukan sekadar pemutus tagihan. Ia juga merupakan sakelar ketersediaan. Sebuah akun dapat menjalankan banyak aplikasi, tetapi batas produk yang sama berlaku secara menyeluruh. Sebelum mengaktifkan usage block, pemilik akun perlu memetakan Worker yang berbagi akun, memisahkan lingkungan produksi dan uji bila memungkinkan, serta memastikan ada jalur pemulihan ketika aplikasi berhenti menerima invokasi. Untuk sistem yang harus tetap hidup, email alert mungkin lebih aman daripada pemblokiran otomatis.
Cloudflare juga memperingatkan bahwa spending limit bukan jaminan nilai maksimum invoice. Pelaporan penggunaan dan penerapan pemblokiran membutuhkan waktu. Operasi yang sudah berjalan dapat terus menghasilkan biaya, dan sebagian penggunaan mungkin sudah tercatat setelah ambang terlampaui. Pada Durable Objects, data yang tersimpan tetap dapat menimbulkan biaya meski operasi baru sedang diblokir. Invoice akhir tetap menjadi catatan pembayaran yang berlaku.
Jika layanan terhenti, pengguna dapat menaikkan batas melewati biaya periode berjalan, menonaktifkan atau menghapus kebijakan pemblokiran, atau menunggu periode penagihan berikutnya. Perubahan memerlukan waktu beberapa menit untuk diterapkan. Batas juga mengikuti periode langganan, bukan selalu bulan kalender; periode dapat dimulai ketika langganan berbayar aktif.
Peluncuran ini relevan bagi pengembang yang menjalankan kode berbasis event, API, atau AI di Cloudflare. Sistem yang mengalami lonjakan trafik, loop pemanggilan, atau salah konfigurasi dapat mengonsumsi resource lebih cepat dari perkiraan. Namun, memasang batas tanpa memahami cakupan akun bisa mengubah masalah biaya menjadi gangguan layanan. Pilihan yang masuk akal bergantung pada toleransi downtime: alert untuk visibilitas, usage block untuk pagar biaya yang juga sengaja menerima risiko penghentian.
Sumber https://blog.cloudflare.com/spend-management/ Dokumentasi: https://developers.cloudflare.com/billing/manage/spend-management/ Dokumentasi Workers: https://developers.cloudflare.com/workers/platform/spend-management/ Dokumentasi Durable Objects: https://developers.cloudflare.com/durable-objects/platform/spend-management/