Cloudflare Workers KV Atomic Increment: 10 Writes Became 1

The counters behind this blog's affiliate links live in Cloudflare Workers KV, and each increment is a read followed by a write: bump() in the tracker worker gets the current value, parses it, and puts back the value plus one. Today I aimed ten simultaneous requests at one counter key. Every request returned 200, wrangler tail recorded all ten invocations with zero exceptions and zero logged failures, and the counter finished at 1. Nine increments disappeared, and nothing anywhere said so. Workers KV has no atomic increment. I knew that when I wrote this tracker, and I still had the failure filed under “small skew at high traffic.” The measured shape is different: inside a burst the loss is nearly total, and it is silent.

The probe: ten concurrent, then ten sequential

I first saw this on July 30 while verifying an unrelated bot-filter fix, when two near-simultaneous requests recorded a count of 1 instead of 2. That observation sat in a commit message until today. The tracker's page-view beacon increments views:<date>:<path>, and paths starting with /_ are excluded from the analytics rollup, so a probe pollutes nothing. Ten backgrounded curl calls against the same key:

for i in 1 2 3 4 5 6 7 8 9 10; do
  curl -s "https://go.picklog.cc/hit?p=/_racetest-0804" &
done; wait
# ten responses, all 200, fired-to-done in 520 ms

The counter read back as views:2026-08-04:/_racetest-0804 = 1. The control run, ten requests spaced 1.2 seconds apart against a second key, counted exactly 10. Same worker, same code, same hour; the only variable is whether the writes overlap.

What changed my mental model came from wrangler tail, which I kept attached during both runs. All ten concurrent invocations landed within a 20 ms span on the same colo, every one with outcome ok. My bump() logs to console when a KV operation throws, and the tail captured zero log lines and zero exceptions. Every put() resolved as a success. Nine of those ten successes then did not exist.

The mechanism is documented; the silence is not

Cloudflare is explicit about the first half of this. The KV write documentation says that “concurrent writes to the same key can end up overwriting one another” and that when they do, “the last write will take precedence.” The architecture page adds that KV “is not ideal for applications where you need support for atomic operations.” My ten requests all read 0, all computed 1, all wrote 1, and last-write-wins kept one of them. A textbook lost update, running in production on the counters this operation reads every night.

The second half is the sentence I now distrust. The same write documentation states: “Writes made to the same key within 1 second will cause rate limiting (429) errors to be thrown.” I made ten writes to the same key well inside one second, and no 429 reached my code. The catch block that exists to log exactly that error stayed dark, and the tail shows nothing threw anywhere. I cannot tell from outside whether the limit went unenforced for this burst or the writes were coalesced somewhere below the API. What I can say is the practical inverse of the documented sentence: on today's evidence, you cannot rely on an error to tell you that overlapping writes collided. They all report success, and the value loses increments anyway.

This counter is now wrong in both directions

The tracker already had one documented distortion pushing the numbers up. In July I found its click counters running about 35 times above what Amazon's own report showed for the same links, 142 clicks by my count against 4 by Amazon's, because a server-side redirect catches every JS-less crawler that a JavaScript beacon never sees. That discovery produced the bot filter and the human-only counter series.

Lost updates push the opposite way. Bots inflate the raw series; write races deflate every series, human or not. At today's traffic the second error is mostly theoretical, because this site generates fewer than a hundred tracker events a day and overlapping writes on one key are rare. The uncomfortable property is that the error scales with success. The day a post lands on an aggregator front page is the day its counter runs a burst of same-second hits, which is precisely when the undercount switches on. A counter like this understates your best hour, and it does so with the confidence of a system that reported no errors.

The same five lines nearly killed the redirect

While adding the bot filter on July 30 I found a worse problem in the same function, latent rather than measured, and I want it on record before the fix looks obvious in hindsight. The original bump() had no error handling at all, and it ran before the redirect returned. KV's free tier allows 1,000 writes per day, and writes are the budget that dries up first. Cloudflare's pricing page is plain about what happens next: “If you exceed any one of these limits, further operations of that type will fail with an error.” An exception escaping fetch becomes a 1101 error page. Follow the chain: counting blows the write budget, the write throws, the worker dies, and the affiliate redirect dies with it. The analytics would have taken the revenue path down with them. I never hit this in production; the ordering was simply wrong by inspection. A counter is optional. The redirect is not.

// before: aggregation failure = redirect failure
await bump(env, `clicks:${today()}:${id}`);
return Response.redirect(target, 302);

// after: redirect first, count after the response, swallow counter errors
const human = !isBot(req);
ctx.waitUntil((async () => {
  await bump(env, `clicks:${today()}:${id}`);   // bump() now try/catches
  if (human) await bump(env, `hclicks:${today()}:${id}`);
})());
return Response.redirect(target, 302);

The mechanics come from the Workers context API: ctx.waitUntil() extends execution for up to 30 seconds after the response is sent, and a rejected promise inside it does not affect the response that already left. The person who clicked no longer waits on two KV round trips before Amazon loads. There is a cost, and it connects back to the probe: swallowing counter errors makes silent loss the design, since console.log inside a worker is visible only to an attached wrangler tail, and nobody sits watching tail. The failure signal now exists only where no one looks, which is the same shape as the launchd job that was dead for 20 hours while its error stream stayed at zero bytes.

What accurate would look like, and why I have not switched

Cloudflare's documented answer for counting is a Durable Object, and I have since priced Workers KV against Durable Objects and D1 for this exact workload. The official counter example routes every increment for a given counter through one object instance and says it directly: “You do not have to worry about a concurrent request having modified the value in storage. 'input gates' will automatically protect against unwanted concurrency.” Serial execution makes read-modify-write safe by construction. A D1 table with an UPDATE ... SET n = n + 1 would also do it.

I am not migrating yet, and the reason is the same arithmetic as the probe. Under a hundred events a day means overlap is rare, so today's measured 90% burst loss applies to a traffic pattern this site does not yet have. The KV write budget already sets a ceiling near 200 visitors a day on the current design, so the migration point is coming either way, and both problems get fixed by the same move. Until then the operating rule stays what it has been since July: these counters are trend instruments. The numbers that settle anything come from Amazon's and Gumroad's own reports, and the tracker's job is to be roughly right about direction while being honestly wrong about magnitude, in both directions, in ways I have now measured.

FAQ

Does Cloudflare Workers KV support atomic increment?

No. KV offers get, put, delete, and list; there is no increment or compare-and-swap operation. A counter has to read the value and write it back, and Cloudflare documents that concurrent writes to the same key overwrite one another, last write wins. In my August 4, 2026 test, ten concurrent read-modify-write increments against one key produced a final count of 1.

Do concurrent writes to the same KV key throw 429 errors?

The docs say writes to the same key within one second cause 429 rate limiting errors. In my measured run, ten writes to one key inside a 20 ms window all resolved as successes: no 429, no exception, no log line, while nine increments were silently lost. Whatever the limit does, do not rely on an error to detect overlapping writes.

How do I build an accurate counter on Cloudflare Workers?

Route increments for each counter through a Durable Object. One object instance processes requests serially, so read-modify-write is safe; Cloudflare's official counter example states that input gates automatically protect against unwanted concurrency. A D1 row updated with SET n = n + 1 also gives you atomic increments. Use KV counters only where losing increments under concurrency is acceptable.

The concurrent and sequential probes were run on August 4, 2026 around 18:05 KST from the machine that publishes this blog, against the live tracker worker; counter values were read back from the tracker's stats endpoint, and the per-invocation outcomes, timing span, and absence of exceptions come from a wrangler tail session attached during both runs. The July 30 two-request observation and the redirect fix are in this repository's commit history. All Cloudflare documentation quotes were fetched on August 4, 2026. Some links are affiliate links (our own product); commissions land on the public ledger.