Cloudflare Worker Logs Not Working? Here's Why (and the Fix)

You added console.log() to your Cloudflare Worker, deployed it, opened the dashboard — and nothing's there. Or logs show up 15 minutes late. Or they appear for one route and not another. This post walks through every reason Worker logs go missing, in the order you should check them.

The 7 reasons your Worker logs aren't showing up

1. You're looking in the wrong place (most common)

console.log() in a Worker does not go to the Cloudflare dashboard by default. Workers Logs must be enabled first: Workers & Pages → your Worker → Logs → Begin log stream (live tail), or Logs → Enable Workers Logs for the persistent stream. Until you do, your logs are emitted into the void.

Even then, the live tail only shows logs while you're actively watching, and the persistent stream lags and samples under load.

2. The Worker crashed before your log ran

If your Worker throws during module initialization, or gets killed by a CPU timeout (10ms on the free plan) or memory exhaustion (128MB), execution stops where it is. Logs before the crash line exist in principle — logs after it never run. If you see partial logs that just stop, your Worker died mid-request.

This is the scenario an SDK can't fix: your logger.error() call is after the crash. A Tail Worker can — it runs after your Worker finishes, success or crash, and receives the execution outcome from Cloudflare's runtime, including the exception and stack trace.

3. Workers Logs sampling is eating your logs

Workers Logs (the paid persistent stream) has a sampling rate — at high request volume, only a fraction of invocations get logged. If you're testing by hammering an endpoint, you may see one log out of fifty requests. Check the sampling config before assuming logs are "lost."

4. The 15–60 minute dashboard lag

Cloudflare's metrics and log views are not real-time. If you deployed two minutes ago and see nothing, wait. If your debugging session depends on seeing logs as requests happen, you need a live tail — or an external pipeline built for real-time delivery.

5. Logs that exceed limits get dropped

Workers Logs drops individual log messages over 128KB and has per-invocation log-volume limits. If you're logging huge JSON payloads (a full request body, a big DB result), that's your answer. Log a summary or a hash instead.

6. You're filtering by the wrong thing

The dashboard's log view filters by status, and some views default to filtering out successful requests. A console.log() in a request that returned 307, or that was served from cache, may be hidden behind the default filter. Clear all filters before concluding logs are missing.

7. Static asset requests don't invoke your Worker

Requests served directly from static assets (Workers Assets, or Pages static content) never run your Worker code — so they never log anything. If only some routes log, check whether the silent ones are hitting assets instead of your fetch handler.

The structural problem

All of the above share one root cause: your logs live inside your Worker's lifecycle. If the Worker is slow, crashed, killed, or never invoked, the logs are lost or delayed with it. Cloudflare's own dashboards add lag and sampling on top.

The fix is to capture execution data outside your Worker. Two layers:

1. A Tail Worker — Cloudflare runs it after every invocation with the full outcome: exceptions, CPU time, duration, request details. It sees crashes your code can't log. FlareLog's open-source template deploys in about 5 minutes.
2. An SDK for in-request logging — structured logs with trace IDs for everything that does run, shipped out-of-band so a slow upstream doesn't take your logs down with it.

How to know your logs are working

After wiring both layers, this is what "working" looks like:

• A crash at 2am shows up in your dashboard (or Slack) within seconds — with the stack trace and the request that triggered it
• You can search last month's logs, not just the last 7 days
• A cost spike from a misconfigured loop alerts you before the invoice does

FlareLog bundles both layers — Tail Worker capture, structured SDK logging, real-time alerts, 90-day retention on Pro — with an MCP server so Cursor or Claude can query the logs directly. Start free with 10,000 logs/month, no credit card.

FAQ

Why is my console.log not showing in Cloudflare Workers?

Usually one of: Workers Logs isn't enabled for the Worker, the dashboard view is lagging or filtering, the Worker crashed before the log line executed, or sampling dropped the invocation. Enable the log stream first, then check whether the requests in question actually invoke your Worker.

How long does Cloudflare keep Worker logs?

Workers Logs retention is 3 days on the paid tier (7 on some legacy configs), and the live tail only exists while you're watching. FlareLog keeps logs up to 90 days on Pro so incidents from weeks ago stay searchable.

Do console.log calls cost money in Workers?

The console.log itself is free; what costs is the Workers Logs ingestion beyond your plan's included volume, and (indirectly) any CPU the logging adds. Logging huge payloads can also hit per-message size limits and get dropped.

What's the difference between wrangler tail and Workers Logs?

wrangler tail is a live CLI stream of one Worker's invocations — great for local debugging, gone the moment you close the terminal. Workers Logs is the persistent dashboard stream, with lag and sampling. Neither captures crashes that kill your Worker before logs emit — that's what a Tail Worker is for.