The Problem Nobody Talks About
You deploy a Worker. It works. Then one day it doesn’t — or worse, it works but something is off. A tool call takes 8 seconds instead of 200ms. A WebSocket connection drops. An AI response comes back empty. Rate limiting fires on a legitimate user.
Without logs, you’re guessing. With the wrong logs tool, you’re drowning in data that doesn’t answer your question.
Cloudflare now has three separate tools for understanding what your Workers are doing, and they serve very different purposes. I enabled all of them on saltwaterbrc.com — here’s what each one does and when to reach for it.
Tool 1: Workers Observability — Your Daily Dashboard
What it is: A built-in observability dashboard for all your Workers and Pages Functions. Lives in the Cloudflare dashboard under Workers & Pages → Observability.
Who it’s for: Developers running Workers in production who need to monitor performance, debug errors, and understand traffic patterns.
How I enabled it: Two lines in wrangler.jsonc:
"observability": {
"enabled": true,
"head_sampling_rate": 1
}That head_sampling_rate: 1 means 100% of requests get logged. For high-traffic Workers you might dial this down, but for my AI agent handling a few hundred requests a day, full sampling is fine.
What You Get
Workers Observability has two main views:
Overview shows logs from all your Workers in one place. You can toggle between Invocations (grouped by the fetch/WebSocket trigger that started the Worker) and Events (every log line in chronological order). This is where I go first when something looks wrong — I can see every request across my Agent V3, API demo, and counter Workers without switching between them.
Investigate is the Query Builder. This is the powerful part. You can write structured queries to slice your logs:
$workers.outcome = "exception"— find all crashes$workers.wallTimeMs > 5000— find slow requests (anything over 5 seconds)status = 429— find rate-limited requests$metadata.error EXISTS— find anything with an error attached
The query language supports comparison operators (=, !=, >, <), functions (contains(), startsWith(), regex(), exists()), and boolean logic (AND, OR, NOT). Queries sync with the visual Query Builder sidebar, so you can write raw queries or click through filters — they stay in sync.
What It Actually Looks Like
Over the last 7 days, my Agent V3 Worker logged 908 successful events and 4 exceptions. The events view shows the full lifecycle of each interaction — WebSocket connections opening and closing, chat responses completing, tool calls firing. Crawlers hitting /sitemap.xml and /robots.txt. Even scanners probing for /xmlrpc.php and /wp-login.php on a Worker that obviously isn’t WordPress.
The 4 exceptions? All websocket:close events with code 1006 — abnormal closure. Someone’s browser tab closed mid-conversation, or their connection dropped without a clean WebSocket handshake. I found this in seconds by typing $workers.outcome = "exception" in the query bar. Each error expands into a structured JSON payload showing the exact Durable Object instance, script version, wall time, CPU time, and the WebSocket close code. Without observability, these would have been invisible — the agent would just stop responding from the user’s perspective, and I’d have no idea why.
Dashboard URL: dash.cloudflare.com → Account → Workers & Pages → Observability
Tool 2: Log Explorer — Why You’re Buying This
Workers Observability tells you what your code is doing. Log Explorer tells you what’s happening to your traffic — the full Cloudflare request lifecycle including firewall blocks, WAF events, bot detection, cache behavior, and DDoS mitigation.
Within 12 hours of enabling Log Explorer on saltwaterbrc.com, I found this in the Firewall events dataset:
| IP | Country | Path | Action |
|----------------|---------|--------------------------------|--------|
| 2.57.122.173 | RO | /docker/.env | block |
| 2.57.122.173 | RO | /secrets/.env | block |
| 2.57.122.173 | RO | /.github/workflows/secrets.env | block |
| 2.57.122.173 | RO | /kubernetes/secrets.env | block |
| 85.11.167.155 | | /.git/config | block |
| 85.11.167.155 | | /wp-config.php | block |
| 107.175.136.30 | US | /.env | block |Automated credential scanners probing for exposed environment files, Docker secrets, Kubernetes configs, WordPress files, and git repos. All blocked by the WAF. I didn’t know this was happening until I looked.
That’s the pitch: you can’t respond to what you can’t see.
What You’re Replacing
Most enterprises already have this visibility — they’re paying for it. They’re forwarding Cloudflare logs through Logpush to Datadog, Splunk, or Sumo Logic, then paying those vendors to store and search data that originated on Cloudflare’s network. The pipeline looks like:
Cloudflare edge → Logpush job → S3/GCS/Azure → SIEM ingestion → SIEM query
Every hop adds cost, latency, and failure points. Schema mappings break. Ingestion pipelines lag. And you’re paying per-GB ingestion fees on top of storage fees on top of query fees. For a mid-size enterprise, that’s $50k-$500k/year just to search your own Cloudflare logs.
Log Explorer collapses that entire pipeline:
Cloudflare edge → R2 (same network) → SQL query
No forwarding pipeline. No ingestion lag. No schema mapping. The logs stay on Cloudflare’s network with all the native context — Ray IDs, security verdicts, bot scores, cache status — intact and queryable. Billing is $0.10/GB/month for storage, and queries are free. No per-scan fees, no surprise bills for running too many searches during an incident.
What You Can Actually Do
Log Search — filter and explore historical logs in the dashboard or via Custom SQL. Query across HTTP requests, firewall events, DNS logs, and more. Save queries for repeated use and share them across your team.
Custom Dashboards — build persistent visual monitors. Track 5XX errors by country, firewall blocks by rule, bot traffic trends, API latency distributions. Enterprise accounts get up to 100 dashboards, with templates to get started fast.
SQL API — run queries programmatically from scripts, CI/CD pipelines, or your own monitoring tools. Standard SQL, no vendor-locked query language.
Security Analytics integration — pivot directly from Security Analytics into Log Explorer with filters preserved. See a suspicious pattern in analytics, click through to the raw logs.
Key Details
- Storage: Logs stored in R2, single-tenant per customer
- Collection: Forward-only — starts when you enable a dataset, no backfill
- Retention: Up to 90 days standard, up to 2 years for contract customers
- Ingestion: Up to 50,000 records/second
- Field selection: Choose exactly which fields to ingest per dataset (since March 2026) to control cost and noise
- Datasets: HTTP requests, Firewall events, DNS logs, NEL reports, Page Shield, Spectrum events, Zaraz events (zone-level) plus Access requests, Gateway, Zero Trust (account-level)
Dashboard URL: dash.cloudflare.com → Account → Log Explorer
Availability: Paid add-on for any Application Services or Zero Trust purchase. $0.10/GB/month. No free tier.
Tool 3: Local Explorer — Debug Your Bindings in the Browser
What it is: A browser-based interface for viewing and editing the data in your local bindings during development. Available at /cdn-cgi/explorer on your local dev server.
Who it’s for: Anyone running wrangler dev who wants to inspect KV, D1, R2, or Durable Objects state without writing throwaway code or running CLI commands.
How I use it: This one showed up with the new cf CLI announced during Agents Week 2026. When I’m developing Agent V3 locally, I start wrangler dev and press e in the terminal — Local Explorer opens in my browser.
What You Can Do
Instead of running wrangler kv:key get or writing a one-off script to check what’s in your D1 database, you just look at it:
- KV: Browse keys, view values, add test data
- D1: Run ad-hoc SQL queries, inspect tables, seed test records
- R2: Browse objects, check metadata
- Durable Objects: Inspect stored state
For my Agent V3, this means I can check what the guestbook table looks like in D1, verify that memory keys in KV have the right TTLs, and confirm that generated images actually landed in R2 — all without leaving the browser.
When It Matters
Local Explorer solves the “did my code actually write what I think it wrote?” problem. Before this existed, debugging a Durable Object meant adding console.log statements, restarting wrangler dev, making a request, reading the terminal output, and repeating. Now I just look.
Requirements: Wrangler 4.82.1+ or Cloudflare Vite plugin 1.32.0+
URL: localhost:{port}/cdn-cgi/explorer during wrangler dev
Which Tool When?
| Scenario | Tool | Why |
|---|---|---|
| ”My Worker is throwing errors in production” | Workers Observability | Filter by $workers.outcome = "exception", see stack traces, wall times |
| ”Someone is attacking my site” | Log Explorer | Historical security events, firewall blocks, bot scores, DDoS patterns |
| ”Did my D1 write actually work?” | Local Explorer | Inspect the local database during development |
| ”What’s my p95 latency?” | Workers Observability | Query Builder with wall time grouping |
| ”We need 90 days of HTTP logs for compliance” | Log Explorer | Long-term storage on R2, SQL queryable |
| ”I need to seed test data in KV” | Local Explorer | Add keys directly in the browser |
| ”Which Cloudflare rules blocked this request?” | Log Explorer | Full request lifecycle including WAF, bot, cache |
Enabling Everything on saltwaterbrc.com
Here’s what’s live on my site right now:
Workers Observability — enabled on both my Agent V3 Worker and the API demo Worker. Full 100% sampling. Every console.log, console.warn, and console.error in my Worker code shows up in the dashboard. The structured logging I added during the security audit (session IDs, truncated IPs, event types) makes the logs actually useful to filter on.
// wrangler.jsonc — this is all it takes
"observability": {
"enabled": true,
"head_sampling_rate": 1
}Local Explorer — available automatically when I run wrangler dev. No configuration needed. I use it when testing new tools for Agent V3 — write a guestbook entry via the chat, then check D1 in Local Explorer to confirm the row exists.
Log Explorer — enabled with HTTP requests, Firewall events, and DNS logs datasets, all with 90-day retention. One gotcha: Log Explorer only collects forward. When you enable a dataset, ingestion starts from that moment — no backfill. I enabled my datasets on April 17, ran my first query on April 20, and got zero results because the pipeline was still spinning up. By April 21, data was flowing — 213 HTTP requests and 23 firewall blocks in a 12-hour window, including the credential scanning attack I covered above.
The Bigger Picture
A year ago, debugging a Worker meant wrangler tail and console.log. That’s it. Now you have a production observability dashboard with a query language, an enterprise forensics tool with SQL access, and a local debugging UI that shows you your actual data.
If you’re building on Workers and haven’t enabled observability yet, start there. Two lines in your wrangler config. Once you’ve seen what your Workers are actually doing, you won’t go back to guessing.
Next up: I’m working on increasing saltwaterbrc.com’s Agent Readiness Score — Cloudflare’s new metric for how well your site supports AI agents. Currently at 38/100. More on that soon.