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:

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.