Use Cloudflare Workers Observability first if your app lives mostly on Cloudflare. It is close to the runtime, quick to open, and good enough for most debugging. Add an outside logging tool when you need long history, richer search, alerts, or logs from many clouds in one place.
TLDR: Cloudflare Workers Observability is the simple choice for checking Worker errors, requests, latency, and console logs without wiring up a big logging stack. For example, a small API doing 2 million requests per month can spot a spike in 500 errors from 0.2% to 3.1% and fix a bad deploy fast. But if your team needs 30, 90, or 365 days of searchable logs, tools like Datadog, Honeycomb, Axiom, Better Stack, or New Relic may fit better. Think of Cloudflare as the cockpit, and external logging as the airport control tower.
What are Cloudflare Worker logs?
Cloudflare Workers run code at the edge. That means your JavaScript, TypeScript, Rust, or other Worker code runs near users. Fast. Tiny. Very cool. Also a bit weird when something breaks.
Logs help you answer basic questions:
- Did the Worker receive the request?
- Did it crash?
- Was the response slow?
- Which route caused the error?
- Did that “quick fix” make things worse?
You can add logs with console.log(), console.error(), and friends. Cloudflare can then show those logs in its dashboard and observability tools. Simple idea. Huge relief.
What is Workers Observability?
Workers Observability is Cloudflare’s built-in way to see what your Workers are doing. It brings together request data, errors, CPU time, logs, and traces. You do not need to ship every log to a third-party service just to see why your Worker yelled at 2 a.m.
It is especially handy for edge apps. The data is already close to the platform. So the setup feels light. You enable observability, add logs, deploy, and inspect.
Honestly, it feels like the right default. Not fancy. Not bloated. Just enough to say, “Ah, that header is missing again.”
What can you see inside Workers Observability?
The useful bits are easy to grasp:
- Invocation count: How often your Worker runs.
- Error rate: How often it fails.
- Latency: How long requests take.
- CPU time: How much compute your code uses.
- Logs: Messages from your code.
- Traces: The path a request took through your Worker.
This helps with common messes. A broken API key. A slow database call. A route that returns JSON sometimes and soup the rest of the time.
The best part is the feedback loop. Deploy. Watch. Fix. Repeat. Like cleaning a kitchen while the smoke alarm is still judging you.
Where Cloudflare’s built-in logging shines
Speed is the big win. You are already in the Cloudflare dashboard. Your Worker is already there. Your errors are already tied to the platform.
That matters when production is on fire. You do not want to open six tabs, search three indexes, and guess which service ate the log line.
Cloudflare is great for:
- Small teams that want fewer tools.
- Edge-first apps built mostly on Workers.
- Fast debugging after a deploy.
- Basic performance checks by route or Worker.
- Early projects where cost control matters.
If your app is a Worker, KV, Durable Object, R2 bucket, and a simple external API, the built-in view may be all you need.
Where it gets annoying
The pain starts when logs become company memory. Cloudflare’s tools are strong for platform-level insight. But outside logging tools often win when you need deep search, saved queries, alert rules, dashboards, and long retention.
It drives me crazy when a bug happened “sometime last Tuesday” and the only clue is a Slack message that says, “API weird?” That is when short retention or thin search hurts.
You may feel limits around:
- Long-term storage for audits or slow bug hunts.
- Advanced filtering across many fields.
- Multi-service tracing across clouds and databases.
- Custom dashboards for business metrics.
- On-call alerts with rich routing rules.
This does not make Workers Observability bad. It means it has a job. It is not always the whole logging department.
Serverless logging alternatives
External logging tools are built for scale and search. They collect data from many places. That can include Cloudflare Workers, AWS Lambda, Vercel, Kubernetes, Postgres, Stripe webhooks, and cron jobs.
Popular options include:
- Datadog: Strong logs, metrics, alerts, and service maps. Great for larger teams. Can get pricey.
- Honeycomb: Excellent for tracing and high-cardinality questions. Great when you ask odd questions often.
- Axiom: Fast search and friendly pricing for many log-heavy teams.
- Better Stack: Simple log search, uptime checks, and alerts in one clean tool.
- New Relic: Broad monitoring for apps, infra, browser, and serverless.
- AWS CloudWatch: Common for Lambda. Powerful, but the interface can feel like a drawer full of cables.
- Sentry: Best known for error tracking, stack traces, and release health.
These tools help when your app is not just Cloudflare. Maybe your Worker calls Lambda. Lambda calls DynamoDB. A queue triggers another function. Then a background job sends email. One failed order can cross five systems.
In that setup, one dashboard is gold.
Workers Observability vs alternatives
Here is the simple version.
| Need | Best fit |
|---|---|
| Debug a failing Worker fast | Cloudflare Workers Observability |
| See edge latency and Worker errors | Cloudflare Workers Observability |
| Search logs across many services | External logging tool |
| Keep logs for months | External logging tool |
| Create rich on-call alerts | External logging tool |
| Control cost on a small project | Cloudflare first |
A simple user case
Say you run a SaaS app with a Worker API. It handles login, billing webhooks, and image resize requests. You average 80,000 requests per day. Most days are boring. Beautiful.
Then a new release ships at 10:00. At 10:07, support gets ten reports. Users cannot upload avatars. Workers Observability shows a jump in errors from 0.1% to 6.4%. Logs show R2_BUCKET is undefined. Ouch.
You roll back. The error rate drops in two minutes. Built-in Cloudflare logging wins here. It was close, fast, and clear.
Now imagine finance asks for every failed billing webhook from the last 180 days. You also need to connect each failure to Stripe, email delivery, and account status. That is external logging territory.
Best practice: use both, but start small
You do not need a huge setup on day one. Start with Cloudflare Workers Observability. Add clear log messages. Include request IDs. Log enough context to debug. Do not log secrets. Never log tokens. Future you deserves kindness.
A good log line might include:
- Request ID
- User ID if safe and allowed
- Route name
- Status code
- Error message
- External service name
Then add an outside logging tool when the pain is real. Not before. Pick one when you need retention, alerts, team workflows, or cross-service search.
Final recommendation
Cloudflare Workers Observability is the best first stop for Cloudflare Worker logs. It is fast, simple, and close to your code. For many teams, that is enough.
But serverless apps grow sideways. A Worker becomes five services. A quick API becomes a checkout system. At that point, use Cloudflare for edge truth and a logging platform for the full story.
Keep it simple. Watch the errors. Save the useful logs. And when your dashboard starts looking like a crime board with yarn, it is time for a proper logging tool.