What could be performance impact with Sentry on Cloudflare Workers?

[Perdolique]

The worker should return the result to the client as soon as possible, and logging/tracing can increase response time. But how does Sentry work in that case? Will it run all the logic within the main request context, and the response will be delayed, or delay requests to Sentry inside waitUntil, for example?

[MILLERMARRU]

The short version: withSentry is built around the Workers execution model specifically so it doesn't hold your response hostage. Capturing an error or finishing a span is synchronous/cheap (it just queues the event locally), it's the network request that actually ships the event to Sentry's ingest endpoint that's the potentially slow part, and that's the part that gets deferred.

Cloudflare Workers only keep running after you return a Response if you register work with ctx.waitUntil(promise), otherwise the runtime is free to tear down the isolate the instant the response is sent. Since withSentry receives your handler's ctx (the ExecutionContext) as part of wrapping it, that's the mechanism it has available to flush queued events after your response goes out rather than before, this is really the only viable way for any Workers-targeting SDK to do telemetry without adding latency to every request, given waitUntil is the platform's sanctioned "do this after I've responded" primitive.

Practically: your fetch handler's actual logic and the client response timing shouldn't be affected by whether Sentry is capturing that request or not, the send-to-Sentry network call happens in the post-response waitUntil window, not inline in your request path. Where you would see a cost is CPU time inside the isolate (span bookkeeping, stack trace construction on errors), which does count against your Worker's CPU limit even inside waitUntil, but that's a much smaller and more predictable cost than "wait for Sentry's ingest endpoint to respond" would be.

If you want to confirm this for your specific setup rather than take the general Workers execution model on faith, wrapping your handler and logging timestamps around your return new Response(...) with and without a Sentry span active is the cleanest way to measure it directly, since the actual numbers will depend on your tracesSampleRate and how many spans/breadcrumbs you're generating per request.