Sentry Next.js edge runtime: its own config, its own limits

# Sentry Next.js edge runtime: its own config, its own limits

## The file

`Sentry.edge.config.ts` initializes Sentry for middleware and edge-route code. Keep it minimal:

```ts
import * as Sentry from "@sentry/nextjs";

Sentry.init({
  dsn: "___PUBLIC_DSN___",
  tracesSampleRate: 0.1,
  // no Node-only integrations here
});
```

`instrumentation.ts` loads it only when `NEXT_RUNTIME === "edge"`. If edge errors are missing while Node.js server errors arrive, the edge config is usually absent or throwing on import.

## What breaks at the edge

The edge runtime has no Node.js APIs: no `fs`, no `process.nextTick` tricks, no native modules. Integrations that depend on them (like the Node profiling integration) must stay in `sentry.server.config.ts` only. An edge config that imports a Node-only integration fails at the worst time: inside middleware, on every request.

Also keep `beforeSend` lean here. Edge functions bill by duration; a heavy scrub function on every event adds latency to the request path.

## Adblockers eat client events

Browser extensions block requests to ingest endpoints. `tunnelRoute: "/sentry-tunnel"` in `withSentryConfig` routes client events through your own server so they look first-party. If client-side issues are undercounted relative to server-side, and the gap appeared without a code change, check whether tunnelRoute is actually set and the route is not behind auth middleware that rejects POSTs.

## Debugging edge init

Edge console output is harder to reach. Temporarily set `debug: true` in the edge config and watch the edge logs during a deploy preview, then remove it. Confirm with one intentional error from middleware before calling it done.