Skip to content

Observability

Every deployed Worker ships with Cloudflare Workers Observability enabled and an error-rate notification configured in the Cloudflare dashboard.

{
"observability": {
"enabled": true,
"head_sampling_rate": 1
}
}

Use head_sampling_rate: 1 for small client apps and early production launches so rare errors are visible. Lower it only when traffic volume makes full traces too noisy or expensive.

Create the alert in Cloudflare Dashboard:

Workers & Pages → your Worker → Observability / Logs → Notifications

The minimum alert is an elevated error rate or repeated exceptions routed to email.

Product apps and apps with paying users add Sentry on top of Workers Observability.

Install the Cloudflare SDK:

Terminal window
pnpm add @sentry/cloudflare

Sentry’s Cloudflare SDK requires AsyncLocalStorage, so add one compatible flag:

{
"compatibility_flags": ["nodejs_als"]
}

Store SENTRY_DSN in Infisical and sync it as a Worker secret. Do not put the DSN in public vars.

Better Auth 1.6 emits OpenTelemetry spans for auth API calls, hook lifecycle, plugin work, and database operations once a tracer provider is registered. ORPC also treats OpenTelemetry as a first-class integration path. The Fenod default is to keep those spans available and choose a collector/exporter at the app level rather than disabling instrumentation in libraries.

Workers Observability gives the baseline logs/traces view. Product apps that need cross-service traces should wire an OTel collector/exporter through the same observability decision as Sentry.

  • Sampling can hide rare errors. Use full sampling until traffic proves otherwise.
  • Alerts without a notification channel are decorative, not observability.
  • wrangler tail is useful for active debugging, but it is not persistent monitoring.

Tier 1 is mandatory for every deployed Worker: observability.enabled = true plus an error alert. Tier 2 is Sentry for product apps, paid-user flows, or any app where silent failures would create client risk.