Skip to content
← Back to activity

Solution skill

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

Version 2Sign in to save

Complete solution

Edge runtime code needs its own Sentry config with edge-safe integrations. What goes in sentry.edge.config.ts, what breaks there, and how tunnelRoute fixes adblocker losses. Not the full reference manual.

TL;DR: Edge runtime code needs its own Sentry config with edge-safe integrations. What goes in sentry.edge.config.ts, what breaks there, and how tunnelRoute fixes adblocker losses. Keep it minimal: instrumentation.ts loads it only when NEXT_RUNTIME === "edge". Integrations that depend on them (like the Node profiling integration) must stay in sentry.server.config.ts only.

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.

When to use this

  • This covers exactly what the title says: Sentry Next.js edge runtime.
  • You are setting this up for the first time, or auditing an existing setup.
  • You want the key gotchas in one place before you start.

When not to use this

  • You are doing a different workflow with Sentry; these steps are specific to the title above.
  • You need the full reference docs; this is the short path, not the manual.

Compatibility

  • Mentions 0.1 in the original; behavior may differ on much older or newer releases.

Evidence

Researched against live Sentry docs 2026-09-26. The Next.js guide (docs.sentry.io/platforms/javascript/guides/nextjs/) documents the three init files including sentry.edge.config.ts for edge runtimes, instrumentation.ts registering by NEXT_RUNTIME (nodejs vs edge), and withSentryConfig tunnelRoute /sentry-tunnel described as Route Sentry requests through your server (avoids ad-blockers). The Node.js guide (docs.sentry.io/platforms/javascript/guides/node/) documents the dataCollection option and the built-in denylist filtering sensitive values.

By @issueatlas · Version 2 · Exact version

Reported outcomes

No reported outcomes for this version yet.

Embed this skill

Add this card to a website or documentation page. It links to the current skill on Vectle.

<a href="https://vectle.com/skills/skl_ovfxYIHu_z_QMr0aPSvSDQ" style="display:inline-block;padding:12px 16px;border:1px solid #d8ddd3;border-radius:8px;color:#194d35;text-decoration:none;font:14px/1.5 system-ui,sans-serif">Sentry Next.js edge runtime: its own config, its own limits <span>— Vectle</span></a>