Production logs and traces may capture sensitive request or error data by default
Source references: 5The Skill directs production Workers to enable logs and traces and provides structured examples that record request paths and raw error messages. Paths can contain user or resource identifiers, while exception messages can expose inputs or internal-service details. It does not require redaction, access restrictions, or retention limits.
If an agent applies this guidance to a Worker handling sensitive traffic, Cloudflare's logging system and people with log access may receive data that should not be retained there. Full log sampling may also increase observability costs.
This is a legitimate production-observability recommendation, not a covert collection mechanism. However, the risk is plausible: the Skill directs users to enable production logs and traces and demonstrates logging request paths and raw exception messages. If a path contains user/resource identifiers, or an exception echoes input, tokens, or internal details, that data would enter Cloudflare logs. The shown guidance does not pair this with redaction, access-control, or retention requirements. Users can ask for explicit sensitive-field filtering, log-access controls, sampling, and retention rules.
## Enable ObservabilityEnable [Workers Logs](https://developers.cloudflare.com/workers/observability/logs/workers-logs/) and [Traces](https://developers.cloudflare.com/workers/observability/traces/) when creating or preparing a Worker for production. Set `observability.enabled` and `observability.traces.enabled` to `true`; the top-level setting alone does not enable traces. Use structured JSON logging and configure sampling for the workload. During reviews, flag missing logs or traces. See the [configuration example](references/configuration.md#enable-workers-logs-and-traces).Show 4 other places
Enable Workers Logs and Traces in Wrangler config before deploying to production. Set `observability.enabled` and `observability.traces.enabled` to `true`; the top-level setting alone does not enable traces. Use `head_sampling_rate` to control volume and cost. Use structured JSON logging — `console.log(JSON.stringify({...}))` — so logs are searchable. Use `console.error` for errors (appears at error severity in the dashboard).**Check**: logs and traces are enabled in the target deployment environment, with neither disabled by an environment override. Check `observability.enabled`, `observability.logs.enabled`, and `observability.traces.enabled`, accounting for their defaults. Logging uses structured JSON, not string concatenation.```ts// Structured JSON — searchable and filterableconsole.log(JSON.stringify({ message: "incoming request", method: request.method, path: url.pathname }));// Error severityconsole.error(JSON.stringify({ message: "request failed", error: e instanceof Error ? e.message : String(e) }));```{ "observability": { "enabled": true, "logs": { "enabled": true, "head_sampling_rate": 1 }, "traces": { "enabled": true, "head_sampling_rate": 0.01 } }} return Response.json(result); } catch (error) { const message = error instanceof Error ? error.message : "Unknown error"; console.error(JSON.stringify({ message: "unhandled error", error: message, path: new URL(request.url).pathname })); return Response.json({ error: "Internal server error" }, { status: 500 }); }