Cloudflare Worker clientDisconnected: 0 Errors, Dead Route

My tracker's stats endpoint stopped answering. I found out sideways: a routine call to go.picklog.cc/stats hit a 120-second shell timeout while I was looking for something unrelated. Both aggregation endpoints on that Worker were doing it, including /public-stats, which is the one my homepage calls from every visitor's browser.

Cloudflare's metrics for that Worker reported zero errors.

The status it did report was clientDisconnected, and it reported that because of something I did rather than something the Worker did. Below are six invocations against production on 2026-08-24, from Seoul, and what each observability surface said about them.

The same request, three different verdicts

I called the two aggregation routes with different curl --max-time values and changed nothing else: same Worker, same script version, same KV namespace.

Request	Client timeout	Result	Wall time
/go/playbook (redirect)	20s	302	0.636s
/stats	20s	no response	20.150s
/public-stats	25s	no response	25.144s
/public-stats	60s	no response	60.129s
/stats	300s	500, error code: 1101	124.376s
/public-stats	420s	500, error code: 1101	125.862s

The endpoint is broken in a specific way: it throws after roughly two minutes. Whether you ever learn that depends on how patient your client is, and every check with a timeout under about 124 seconds walks away before the Worker has anything to say.

The two routes also die at nearly the same moment despite reading very different amounts of data, 2,298 keys for /stats against 1,512 for /public-stats. Both stop at the same operation cap on the way, so the failure time is now a constant.

What the platform recorded

Querying workersInvocationsAdaptive in Cloudflare's GraphQL analytics API for that 40-minute window, grouped by status:

status	requests	errors	subrequests	CPU p50	wall p50
clientDisconnected	3	0	0	132.8 ms	59.84 s
success	2	0	0	0.3 ms	0.00 s
scriptThrewException	1	1	0	189.4 ms	125.36 s

The three invocations I abandoned are filed with errors: 0. Only the one where I waited past the throw produced an error. The recorded wall times give the game away: 59.84 seconds against my 60-second timeout, and a p99 of 119.61 seconds against my 120-second one. The invocation record ends when I do.

Cloudflare's metrics documentation defines the status as "HTTP client (that is, the browser) disconnected before the request completed", which is accurate and also reads like an exoneration. The limits page explains why it can go on so long: "There is no hard limit on duration for HTTP-triggered Workers. As long as the client remains connected, the Worker can continue processing." A Worker in a slow loop does not time out. It waits to see who quits first, and whoever quits first writes the record.

The subrequests column says zero too

Every row above reports subrequests: 0, including the invocation that was killed for making too many subrequests. That is not a glitch. The two pages define the word differently. The limits page says "A subrequest is any request a Worker makes using the Fetch API or to Cloudflare services like R2, KV, or D1." The metrics page says subrequests are "requests triggered by calling fetch from within a Worker."

So KV calls count when the limit is being enforced and do not count when the metric is being tallied. If you are trying to spot a KV fan-out problem before it becomes an outage, the column named after it will show a flat zero the whole way.

wrangler tail gives it a fourth name

Tailing the Worker live while the request ran to completion produced the exception text:

"outcome": "exception", "wallTime": 118718, "cpuTime": 195,
"exceptions": [{ "name": "Error", "message":
  "Too many API requests by single Worker invocation. To configure this
   limit, refer to https://developers.cloudflare.com/workers/wrangler/configuration/#limits",
  "stack": "    at Object.fetch (worker.js:101:48)" }],
"response": { "status": 500 }

CPU time is 195 ms against 118,718 ms of wall time, which is 0.16 percent. The stack line is wrong, as it was the last time I caught this Worker throwing: worker.js:101 is inside the /save-links branch, and this request never entered it. I wrote up that lie and the operation counts behind it in listing keys is not reading them, and the error code itself in Workers error 1101.

Then I tailed it again and killed the client at 25 seconds:

"outcome": "canceled", "wallTime": 24864, "cpuTime": 40,
"exceptions": [], "logs": [], "response": null

No exception, no log line, no response status. Watching the Worker in real time, with the failure happening in front of me, the record is empty and the wall time is my own timeout.

That makes four names for two outcomes, depending on which surface you read:

Surface	Client gave up	Worker threw
Dashboard metrics	Client disconnected	Worker threw exception
GraphQL status	clientDisconnected	scriptThrewException
wrangler tail	canceled	exception
Local dev explorer	n/a	ok

The last row comes from an earlier measurement written up in the Wrangler local explorer API: locally, an invocation making 2,406 KV operations, well past the production lethal dose, finishes in 348 ms and is recorded as ok.

Nine days, reconstructed from key names

The counter keys in this namespace are named prefix:YYYY-MM-DD:name and carry no TTL, so a full inventory of the namespace is also a history of it. I listed all 2,304 keys and rebuilt the daily scan size for /public-stats, which reads every views: and clicks: key one at a time.

The reconstruction puts 817 keys on August 11, and when I measured that endpoint directly that day for a different post I counted about 812 operations. Two independently built numbers landing five apart gives me some confidence in the rest of the curve, which crosses 1,000 between August 14 (940 keys) and August 15 (1,043 keys).

My last observed HTTP 200 from /public-stats was on August 13, at 135.900 seconds. Today it is a 500. The public dashboard endpoint has most likely been dead for nine days, and my error count for the Worker has been zero for all nine of them.

The third layer of silence was mine

Cloudflare gets two of the three layers here. The Worker does not fail on its own because there is no duration limit to trip, and the platform files the resulting timeouts against the client. The third layer is my code. This is the entire consumer of that endpoint, at ops/site/index.html:1612:

fetch('https://go.picklog.cc/public-stats').then(r=>r.json()).then(d=>{
  document.getElementById('rev').textContent='₩'+d.revenueKRW.toLocaleString();
  ...
}).catch(()=>{});

An empty catch. Every visitor's browser has been waiting two minutes for a 500 and then discarding it without a console line. I wrote that catch so a tracker outage could not break the page, which it does correctly, and the cost of that choice is that the page cannot tell me it happened. The same shape showed up in a cron job failing silently earlier today, from a different direction.

What I am changing in the alerting

The fix for the endpoint is known and documented. Cloudflare's list keys reference says it outright: "Storing values in metadata is more efficient than a list() followed by a get() per key." A counter kept in key metadata comes back with the listing, which turns 1,512 operations into two.

I have known that since August 11 and did not do it. It sat in a repair queue while the endpoint went from slow to broken. Reporting that honestly matters more here than the fix does, because the fix was never the hard part.

Update, 2026-08-28. Fixed, four days after this post. /public-stats now reads one precomputed key and returned 200 in 0.767 s today; the paginated /stats costs 251 operations per invocation instead of about 2,600. I did not take the metadata route described above, and the reason is the Free plan write cap: backfilling 2,596 keys is two and a half days of the 1,000-writes-a-day budget. The arithmetic is in Too many API requests by single Worker invocation: the fix.

Alerting on error count cannot see this failure, and neither can a health check with a sensible timeout, because a shorter timeout produces a cleaner metric. The wall time distribution can: successful invocations on this Worker sit at 0.00 s p50 while the disconnected ones sit at 59.84 s. A Worker accumulating disconnects on a route nobody cancels by hand is describing an outage in the only vocabulary it has. Query quantiles { wallTimeP99 } and the count of clientDisconnected before you trust sum { errors }, which said zero here for nine days.

The Worker source discussed here, including the click tracker it belongs to, is part of the Playbook ($12).

Measurements were taken on 2026-08-24 from Seoul against the live picklog-go Worker and its production KV namespace: nine curl probes, one full inventory of 2,304 keys through wrangler kv key list --remote 4.125.0, two wrangler tail captures, and one workersInvocationsAdaptive query covering a single 40-minute window. That window holds six invocations from one location, which is a small sample. The roughly 1,000-operation cap is counted from my own key inventory rather than reported by the platform, and the only figure the platform gave me is the exception string. The August 15 crossing is modelled backwards from today's inventory rather than observed on the day; what I actually saw is a 200 on August 13 and a 500 today. I did not check whether Workers Logs, a separate product from the metrics path used here, records these invocations differently, and I could not confirm whether an invocation marked clientDisconnected stops at that moment or keeps running. All I know is that its recorded wall time matches my timeout. Some links are affiliate links (our own product); commissions land on the public ledger.