Cloudflare KV Free Plan: How to Budget 1,000 Writes a Day

Workers KV is the simplest place to keep content on Cloudflare's free plan, and its limits are generous for reading and tight for writing. The limits page (updated 21 April 2026) says 100,000 reads a day, 1,000 writes a day to different keys, one write per second to the same key, 1 GB of storage per account, 25 MiB per value, 512 bytes per key and 1,024 bytes of metadata. Reads are rarely the problem. Writes are. Here is how we count them and stay at an estimated 130 a day for a site that publishes around ten items.

What one published item costs

Every put is a write. Counting from our code:

A normal day of five wallpapers, two prompts, one story and four articles is 20 + 10 + 11 + 16 = 57 writes. Eight production cycles add roughly 50 for status keys and the clock's public heartbeat. That is a bit above 100 writes, and with a few extra keys we estimate about 130. The 1,000 limit leaves room for experiments, which is exactly what you need while you are building.

Habits that keep the count low

1. Never use KV for counters or queues. Writing a hit counter on every request would use up 1,000 writes in the first minutes of real traffic, and two writes to the same key within a second can collide. We keep visitor counts in memory per isolate and flush them in batches to a Durable Object, described in Counting Visitors Without Cookies on a Cloudflare Worker.

2. Write a result once, at the end of the step. Put the bytes in KV inside the Workflow step that produced them and return only the key. If a step is retried, it writes again, so keep steps small and idempotent. We check for an existing slug before adding an index entry, so a retry replaces instead of duplicating. The retry rules are in Cloudflare Workflows Free Plan: Retries, Steps and Fatal Errors.

3. Cache reads at the edge. Pages and images are served through the Cache API with a time to live (three minutes for the home page, a day for media), so almost no page view reads KV. Add a deploy stamp to the cache key and each deploy starts with a clean cache, which avoids serving a stale page for an hour after a fix.

4. Prune by retention, not by hand. The 1 GB storage limit is the other wall. Our retention is per section (400 articles, 400 wallpapers, 90 stories), and old posts are deleted along with their media when new ones push them out. Stories are the heavy ones: each carries four images and four audio files of uncompressed WAV, about 3 MB in total, so 90 stories is already around 300 MB.

5. Store the media type as metadata. A put takes a metadata object of up to 1,024 bytes. We keep the MIME type there, so one key holds the file and its type, with no second write for a record about the file.

A budget you can see

Add one number to your status page: writes you expect per day. When you add a feature, count its writes the way the table does. If you are unsure, remember that you can check the day's usage in the Cloudflare dashboard, and that the limit resets daily.

The same discipline applies to the other free allowance in this stack, the daily AI budget. We worked it out per endpoint in Workers AI Free Tier: What Each API Call Really Costs in Neurons.

FAQ

What are the Workers KV limits on the free plan?

As of the limits page updated 21 April 2026: 100,000 reads per day, 1,000 writes per day to different keys, 1 write per second to the same key, 1 GB of storage, 25 MiB per value, 512 bytes per key and 1,024 bytes of metadata.

Can I use KV for a visitor counter?

Not a good idea. A counter that writes on every visit burns the 1,000 daily writes in minutes and collides with the one write per second limit on the same key. Aggregate in memory and write rarely, or use a Durable Object, which is what we do for traffic counts.

Do page views use my KV read budget?

Only if you read KV on every view. We cache rendered pages and media at the edge with the Cache API and a TTL, so most views never touch KV. On workers.dev we saw cf-cache-status HIT responses for cached pages.

What happens when the daily write limit is hit?

Further writes fail until the day resets. A publishing pipeline should treat that as a normal condition: finish the run without losing data, and try again later.