Local development, traces, and telemetry

Start from the project#

Keep the project’s wrangler.toml, wrangler.json, or wrangler.jsonc in the workspace. The Local Dev view discovers supported bindings and state locations. For example:

[[d1_databases]]
binding = "DB"
database_name = "docs-demo"
database_id = "replace-with-your-database-id"

Use a real identifier for remote operations. Inspect whether the selected view uses local state or a remote service before comparing data. Cloudflare cf Project… provides the published project-creation entry point; the generated project still needs its own runtime configuration.

Follow a Worker trace#

Open a Worker and select Traces. Choose a time window, optionally enter a trace ID, and refresh. Select a trace to inspect its span hierarchy, timings, attributes, and logs. Compare the request you sent with its timestamp and route.

Copy a trace ID when passing the investigation to another developer. Trace data must already be available from the runtime; opening this panel does not enable application instrumentation or populate historical traces.

Navigate only when source is known#

A source-location link requires the exact file/line information supplied by the trace. A span name alone is insufficient to infer a local source line. Check the deployed version against your checkout before trusting navigation into a changed file.

Pagination follows the cursors supplied by the API. A time window and an empty page are not proof that no requests happened outside that window.

Broaden the investigation#

Observability dashboards show available telemetry and charts. GraphQL Explorer supplies predefined queries for supported account analytics. Confirm account, variables, interval, and API permissions before interpreting a chart as application-wide coverage.

Keep metrics and individual requests separate: a chart can reveal a rate change while a trace explains one request. Use the same deployment identity and time range when comparing them.