How much does Cloudflare Workers KV cost?

Free plan limits and daily resets

If you run your code on the Workers Free plan, you don't pay anything for Workers KV, but Cloudflare enforces strict daily ceilings on what your application can do.

On the Free plan, you get:

• 100,000 keys read per day
• 1,000 keys written per day
• 1,000 keys deleted per day
• 1,000 list requests per day
• 1 GB of stored data
• Up to 1,000 namespaces

All daily usage counters reset every day at 00:00 UTC.

What happens when you hit one of those caps? Cloudflare does not quietly charge your credit card or slide you into an overage fee on the Free tier. Instead, if you exceed any one of these limits, further operations of that type fail with an error. If your application pushes 1,001 writes before 00:00 UTC, write number 1,001 simply breaks. That makes the Free plan completely safe from unexpected bills, but it can take your app offline if your traffic ticks up unexpectedly. If your architecture relies on Workers KV alongside other Cloudflare services, check our guide on How does Cloudflare Workers pricing work? to see how the worker runtime itself handles free limits.

Workers Paid plan rates and billing

Upgrading to the Workers Paid plan removes the hard daily limits and swaps in monthly allowances with pay-as-you-go unit pricing. There is no cap on reads and writes to different keys on the Paid plan. You can throw as much traffic at KV as you want, and Cloudflare will simply bill you for the volume at the end of the month.

Every month on the Paid plan includes a baseline allotment of reads, writes, deletes, and storage before metered charges apply.

Data transfer and egress are straightforward: Workers KV does not charge for data transfer or egress at all. You pay for the operations and the stored gigabytes, but moving data out to your users doesn't show up on your invoice.

Namespace billing has a specific mechanic if you generate them dynamically. You get 1,000 namespaces included on the Paid plan by default. If you exceed that baseline, each additional namespace costs $0.10 per month. For example, having 1,050 namespaces on the Workers Paid plan for a full billing month costs $5.00 for the 50 additional namespaces, while read, write, delete, list, and storage charges apply separately.

The write-heavy pitfall: REST, CLI, and null fetches

The biggest billing mistake developers make with Workers KV is treating it like an operational scratchpad. At $0.50 per million, reads are almost negligible, but writes, deletes, and list calls are ten times more expensive at $5.00 per million. If you use KV to track active user presence, log every incoming analytics event, or update rolling counters, those writes pile up fast.

There are three specific operational behaviors that tend to inflate invoices:

1. REST API bulk writes are not discounted

Some developers assume pushing data through the external REST API bypasses per-write pricing or provides bulk discounts. It doesn't. When writing via the Workers KV REST API, each key-value pair in a PUT request is counted and billed as a single write, identical to how each call to PUT in the Workers API counts as a write. For instance, writing 5,000 keys via the Workers KV REST API incurs the exact same write costs as making 5,000 PUT calls inside a Worker.

2. Wrangler and dashboard operations are billable

Admin tasks count toward your bill. Operations performed via the Cloudflare dashboard or wrangler CLI - including updating (writing) keys, deleting keys, and listing keys in a namespace - count as billable Workers KV usage. If you run build scripts or deployment pipelines that purge or repopulate thousands of keys on every commit via wrangler, you are paying standard write and delete rates on every run.

3. Fetches for missing keys still cost money

A common assumption is that an operation only bills if it finds data. With Workers KV, all operations incur charges, including fetches for non-existent keys that return null in the Workers API or HTTP 404 in the REST API. If a bot scrapes your site requesting millions of non-existent cache keys, each lookup hits your bill at standard read pricing.

KV platform limits that affect architecture

Pricing is only half the problem; KV has hard operational constraints that dictate what you can build.

The most critical bottleneck is write concurrency: Workers KV limits writes to the same key to 1 per second on both the Free and Paid plans. If you have multiple Workers scattered across worldwide data centers trying to increment the same key simultaneously, requests will collide and fail. For high-frequency state updates to a single entity, look at How are Cloudflare Durable Objects billed? or structured databases like How does Cloudflare D1 pricing work? instead.

Other core limits to design around:

• Operations per Worker invocation: Workers KV allows a maximum of 1,000 operations per Worker invocation on both Free and Paid plans. Within a single invocation, a Worker can make up to 1,000 total operations to external services (such as 500 Workers KV reads and 500 R2 reads combined). A bulk request to Workers KV counts as 1 request toward this 1,000 external service operations limit.
• Payload sizes: The maximum key size is 512 bytes, while key metadata can reach 1024 bytes. The maximum value size is 25 MiB.
• Key capacity: Keys per namespace are unlimited on both plans. Storage per account and storage per namespace are limited to 1 GB on Free, but are completely unlimited on Paid.
• Cache TTL: If you set a cacheTtl parameter on reads, the minimum allowed value is 30 seconds, while the maximum value is Number.MAX_SAFE_INTEGER.

Workers KV Instant limits

If you are using Workers KV Instant, different operational boundaries apply. KV Instant trades general-purpose scale for lower propagation latency, but the constraints are significantly tighter:

• Writes per namespace: Limited to 1 per second across the entire namespace.
• Storage per namespace: Capped at 1 MB total.
• Namespace keys: A maximum of 10,000 keys per namespace.
• Key size: 300 bytes maximum.
• Key metadata: Not supported.
• Value size: Any size that keeps the total namespace within 1 MB.
• Listing: List pagination is not supported; all matching keys are returned in one response.

Because of the 1 MB ceiling and single write-per-second cap per namespace, KV Instant is intended purely for tiny, rapidly accessed configurations, not general application storage.

Tracking Cloudflare KV spend with Costbrake

If you run Workers KV in production, unexpected traffic spikes or runaway recursive writes can rack up fees before you notice them on your dashboard.

Costbrake watches what you spend across 23 cloud, AI and SaaS providers, including Cloudflare, AWS, Google Cloud, Azure, and Vercel. For Cloudflare, it reads your usage (Workers, R2, Durable Objects, and more) priced at list rates, and pulls in billed dollars roughly a day later.

It monitors your infrastructure continuously:

• Spike alerts: Alerts you if an hour costs more than 3x the usual hour based on a 7-day baseline, provided it is at least $5 over normal.
• Budget tracking: Triggers default alerts at 50%, 80%, and 100% of your budget, along with forecast alerts when your month-to-date run rate plus the last 72 hours points to an end-of-month overrun.
• Reversible brakes: On Pro and Team plans, Costbrake gives you opt-in, reversible brakes for Cloudflare. If an incident spirals out of control, you can turn off workers.dev and preview URLs, pause queue delivery, pause cron triggers, detach custom domains and routes, roll back to the previous version, cap CPU time per request, or block usage with a Cloudflare spend policy. A brake only runs when an admin clicks and confirms it; Costbrake never executes brakes automatically.

You can set up monitoring via read-only Cloudflare API tokens (using Account Analytics Read and Billing Read) or automate it with your AI assistant using our agent setup. Review our flat plans on the Costbrake pricing page; every new workspace starts with a 14-day Pro trial with no card required.