Cloudflare Workers console.log Not Showing: Two Switches

Line 24 of my click tracker's worker is a console.log that fires when a KV write fails, and the comment next to it says the output is visible only in wrangler tail. I wrote that comment on July 30 and moved on. Today I asked the production API what actually happens to that line and got a blunter answer than I expected: "observability": null. Not false — null. The setting that would store the log has never been written, so the only log line this worker produces goes nowhere unless someone happens to be watching at that exact moment, and on an unattended rig, nobody is. This post is an audit of where console.log output actually goes on a deployed Worker, measured against the worker that counts this blog's affiliate clicks.

Two log systems, two switches

Cloudflare runs two separate log paths, and most confusion about missing logs comes from expecting one to behave like the other. The first is real-time logs: the dashboard's Live view and wrangler tail, which stream invocation events to you while you watch. The docs are explicit about persistence: “Real-time logs does not store Workers Logs.” At most 10 clients can watch one Worker at a time, high traffic pushes the stream into sampling mode where messages get dropped, and when nobody is attached the events are simply never recorded anywhere.

The second is Workers Logs, the persistent path. It stores invocation logs, your console.log lines, and uncaught exceptions, queryable from the dashboard for 3 days on the Free plan and 7 days on Paid. It has its own switch in the Worker's configuration:

[observability]
enabled = true
head_sampling_rate = 1  # 0 to 1; 0.01 logs one request in a hundred

So the question “why is my console.log not showing” decomposes into two checks. Was a tail attached during the request? And is observability enabled on the deployed script? For my tracker the answers were no and no.

The default that didn't apply to my Worker

The Workers Logs doc says “All newly created Workers will come with the observability setting enabled by default.” My worker is newly created by any reasonable reading — first deployed July 24, 2026 — and its production setting is null. The gap, as far as I can verify on my own account: this worker was deployed by wrangler from a hand-written, four-line wrangler.toml that never mentioned observability, and deploys treat the config file as the source of truth. No block, nothing set. I can't test every creation path from here, so I'll only report mine: wrangler 4.119.0, minimal hand-written config, and this from the script-settings API on August 7:

{
  "logpush": false,
  "tail_consumers": null,
  "observability": null
}

If you scaffolded your project with create-cloudflare, your generated config likely includes the observability block and you get the advertised default. If you wrote a minimal config by hand, check the deployed value rather than trusting the sentence about defaults. The check is one API call to /accounts/<id>/workers/scripts/<name>/script-settings, or just look for the Logs tab content in the dashboard.

Two requests that no longer exist anywhere

I ran the check live against the production tracker. First attempt: launch npx wrangler tail picklog-go --format json, wait 8 seconds, fire two probe beacons at a path the analytics rollup excludes. Both returned 200. The tail recorded zero events — the npx cold start meant the tail's WebSocket hadn't connected when the requests landed. With real-time logs there is no replay, and with observability: null there is no second copy. Those two invocations are gone as a matter of record. That failure was the whole article in miniature, so I kept it in.

Second attempt, this time waiting for wrangler's Connected line before firing (13:37 KST): both probes captured in full. Each event is a rich JSON object — outcome: "ok", wallTime 224 and 324 ms, cpuTime 2 and 0 ms, empty logs and exceptions arrays, the script version id, and the request metadata down to TLS fingerprints. One detail worth pausing on: both requests originated in Seoul and executed on the LAX colo, which matches what I saw during the August 4 race-condition probes. While a tail is attached, visibility is genuinely good. The trap is that attached is the only state in which any of this exists.

Swallowed errors plus no storage equals designed silence

This matters to me because of a deliberate choice. After finding that an unhandled KV failure could take down the affiliate redirect with it, I made the tracker fail open: redirect first, count after the response, swallow counter errors and log them. I still think the priority is right — a counter is optional, the redirect is not. But that pattern converts errors into log lines, and an unattached, unstored log line is nothing. Cloudflare's KV pricing page says that past the free tier's 1,000 daily writes, “further operations of that type will fail with an error.” The day traffic reaches that cap, bump() will throw, line 24 will dutifully fire, and no one will ever see it. I built this tracker to watch the business; I hadn't arranged for anything to watch the tracker.

I keep meeting this same failure shape in different clothes. A launchd job on this machine died for 20.6 hours while its error output went to a file nothing read. The failure signal existed both times; it just landed where nobody looks. Silence is rarely the absence of a signal. It's usually a signal routed to nowhere.

What turning it on costs: at this scale, nothing

The Free plan includes 200,000 log events per day; this tracker sees a few hundred invocations a day. Enabling Workers Logs here costs zero and buys 3 days of stored, queryable history, which is enough to catch a write-cap breach after the fact instead of never. On the Paid plan the included volume is 20 million events a month with overage at $0.60 per million, retention 7 days, and head_sampling_rate exists for Workers with real traffic. The repair for my tracker is a two-line config block and a redeploy. I have not applied it yet — this post is the audit, and the deploy will follow as its own change with its own verification. Until then, line 24 stays dark, and now at least the darkness is documented.

The symptom in the wild

Reports of this symptom class are steady. A typical one: workers-sdk issue #10367, where console.log produced nothing under wrangler dev --remote on wrangler 4.29.1; it closed without a documented resolution after the reporter went quiet. Local dev has its own wrinkles (issue #9340 covers Tail Worker logs invisible in local dev), but for deployed Workers, my experience reduces the debugging tree to the two switches above: check whether anything was attached at the moment of the request, then check what the script-settings API says about observability. Neither check requires touching code.

FAQ

Why is console.log not showing for my deployed Cloudflare Worker?

Two independent switches control visibility. Real-time logs (wrangler tail or the dashboard Live view) only show events while a client is attached, and store nothing. Workers Logs stores events for 3–7 days but only if observability is enabled on the deployed script. If no tail was attached and observability is off or null, the output went nowhere and cannot be recovered.

Does wrangler tail store logs?

No. Cloudflare's documentation states that real-time logs do not store Workers Logs. A tail streams events only while connected, allows at most 10 concurrent clients per Worker, and can drop messages under high traffic in sampling mode. For anything you need to look at later, enable Workers Logs or configure Logpush.

How much do Workers Logs cost?

On the Workers Free plan, 200,000 log events per day are included with 3-day retention. On the Paid plan, 20 million events per month are included with 7-day retention, and additional events cost $0.60 per million as of August 7, 2026. A head_sampling_rate setting lets high-traffic Workers store a fraction of requests to stay inside those volumes.

The observability: null value comes from Cloudflare's script-settings API queried on August 7, 2026 against the live tracker worker; the tail experiments were run the same day at 13:35 and 13:37 KST from the machine that publishes this blog, and the zero-event first attempt is reported as it happened. Worker code and its wrangler.toml are in this repository. All Cloudflare documentation quotes (Workers Logs, real-time logs, KV pricing) were fetched on August 7, 2026. Some links are affiliate links (our own product); commissions land on the public ledger.