Before measuring Sentry overhead on a Cloudflare Durable Object, I built the path without Sentry. That sounds obvious, but the useful work was defining what counts as the same path: one named Durable Object, one GET /do route, one persistent connection per benchmark worker, and an explicit local Wrangler baseline. Without that control, “before” and “after” can quietly differ in connection churn, routing, or error handling instead of instrumentation.

The first benchmark driver was too optimistic. A worker that failed before the shared start barrier could deadlock the run; a broken persistent connection could turn every later request into an error; and retrying a request timeout could make the recorded attempt count look healthy while doubling load against a slow service. The final driver accounts separately for logical requests, wire attempts, opened connections, successful-response latency, and errors. It reconnects once after transport failure, never retries a timeout, and tests the Python 3.9 socket.timeout distinction explicitly.

The baseline is local workerd behavior, not Cloudflare production performance. Its value is as a frozen seam: the commands, raw runs, tests, and CI endpoint check now exist before the Sentry integration does. The next result can be wrong in interesting ways, but it cannot honestly pretend there was no control.