How to Configure Observability and Logging in Cloudflare Workers: A Complete Guide

Enable the observability flag in wrangler.jsonc and use native console methods to capture traces and logs automatically in the Cloudflare Dashboard.

Configuring observability and logging in Cloudflare Workers is essential for debugging production issues and monitoring application health. The ifindev/fullstack-next-cloudflare repository demonstrates a production-ready setup using built-in Cloudflare features without third-party dependencies. This guide explains how to enable automatic trace collection, implement structured logging, and export logs to external platforms.

Enabling Worker Observability in wrangler.jsonc

Cloudflare Workers provide native observability through a simple configuration flag. In the ifindev/fullstack-next-cloudflare repository, the wrangler.jsonc file contains the observability block at lines 15-17. Setting "enabled": true activates Cloudflare's tracing stack, which automatically injects the cf-trace-id header into every request and enables metrics collection.

{
  "name": "next-cf-app",
  "main": ".open-next/worker.js",
  "compatibility_date": "2025-03-01",
  "observability": {
    "enabled": true
  }
}

Once deployed, view automatic traces in the Cloudflare Dashboard under Workers → Observability. The platform captures request-level IDs, latency metrics, and error rates without requiring any instrumentation code.

Logging with the Native Console API

Cloudflare Workers capture all native console method calls (console.log, console.error, console.warn) and forward them to the Logs UI with automatic trace ID correlation. The ifindev/fullstack-next-cloudflare repository demonstrates this pattern across several modules.

In src/lib/r2.ts (lines 56-62), the code logs R2 upload errors:

// src/lib/r2.ts
try {
  // … upload logic …
} catch (error) {
  console.error("R2 upload error:", error);
  throw new Error("Failed to upload file");
}

Similarly, src/modules/auth/utils/auth-utils.ts (lines 66-70) logs authentication failures, while various files under src/modules/todos/actions/ (such as create-todo.action.ts) log todo CRUD operations. Each log entry automatically includes the request's trace ID, enabling correlation with distributed traces.

Accessing Trace IDs for Correlation

For advanced debugging, you can access the trace ID programmatically to include it in custom log messages or forward to external services. Cloudflare injects the trace context into the request's cf property.

export default {
  async fetch(request: Request, env: Env, ctx: ExecutionContext) {
    const traceId = (request as any).cf?.trace?.traceId ?? "unknown";
    console.log(`[${traceId}] Incoming request: ${request.method} ${request.url}`);

    try {
      const data = await env.next_cf_app.prepare("SELECT * FROM todos").run();
      console.log(`[${traceId}] DB query succeeded – rows=${data.results.length}`);
      return new Response(JSON.stringify(data.results), { status: 200 });
    } catch (err) {
      console.error(`[${traceId}] DB query failed:`, err);
      return new Response("Internal error", { status: 500 });
    }
  },
};

This pattern allows you to follow a single request through your entire application stack, from the edge to database queries, using the consistent cf-trace-id.

Exporting Logs with Logpush

While the Cloudflare Dashboard provides built-in log viewing, production environments often require centralized log aggregation. Cloudflare Logpush allows you to stream Worker logs to external observability platforms without code changes.

To configure Logpush:

1. Navigate to Logs → Logpush in the Cloudflare Dashboard
2. Create a new destination (Datadog, Splunk, AWS S3, or custom HTTP endpoint)
3. Select Worker Logs as the source
4. Enable All Levels to capture console.log, console.error, and console.warn outputs

Once configured, every console call in your Worker automatically streams to your chosen destination with full trace context, enabling correlation with metrics from other services.

Summary

• Enable the observability flag in wrangler.jsonc to activate automatic trace collection and metrics in the Cloudflare Dashboard.
• Use native console methods (console.log, console.error) throughout your Worker code; Cloudflare automatically captures these with associated trace IDs.
• Reference specific files like src/lib/r2.ts and src/modules/auth/utils/auth-utils.ts for production logging patterns.
• Access the cf-trace-id via (request as any).cf?.trace?.traceId to correlate custom logs with Cloudflare's automatic traces.
• Configure Logpush in the Cloudflare Dashboard to stream logs to external observability platforms like Datadog or Splunk.

Frequently Asked Questions

How do I enable observability in Cloudflare Workers?

Add the observability configuration block to your wrangler.jsonc file with "enabled": true. This activates automatic trace collection and metrics without requiring any code changes. Once deployed, view traces in the Cloudflare Dashboard under Workers → Observability.

Where do console logs appear in Cloudflare Workers?

Logs emitted via console.log, console.error, or console.warn appear in the Cloudflare Dashboard under Workers → Logs. Each log entry automatically includes the request's trace ID, allowing you to correlate log messages with distributed traces. You can filter logs by level, time range, or specific text patterns.

Can I export Cloudflare Worker logs to Datadog or Splunk?

Yes, using Cloudflare Logpush. Navigate to Logs → Logpush in the Cloudflare Dashboard, create a new destination, and select your Worker as the source. You can stream logs to Datadog, Splunk, AWS S3, or other supported providers. This requires no code changes—simply configure the destination and select which log levels to forward.

How do I correlate logs with traces in Cloudflare Workers?

Access the trace ID from the request's cf property using (request as any).cf?.trace?.traceId. Include this ID in your console statements to correlate custom logs with Cloudflare's automatic traces. This allows you to follow a single request through your entire application stack, from the edge to your database queries.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}