feat(docs): add sentry

[aidankmcalister]

Summary by CodeRabbit

• New Features
  • Integrated error tracking and monitoring across the documentation site.
  • Global error UI now captures and reports client-side errors and offers a recovery link.
  • Added request/route instrumentation and performance tracing, including router transition capture.
• Chores
  • Added monitoring dependency and environment-specific monitoring configuration to enable Sentry integration.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
docs	Ready	Preview, Comment	Feb 16, 2026 3:20pm

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

---

Walkthrough

Adds Sentry integration to the docs app: dependency, Next.js config wrapper, server and edge initializers, client and shared instrumentation hooks, and an App Router global error component that captures exceptions.

Changes

Cohort / File(s)	Summary
Next.js config & dependency apps/docs/next.config.mjs, apps/docs/package.json	Wrapped existing MDX config with withSentryConfig(...) and added @sentry/nextjs to dependencies; added Sentry options (org/project/authToken/tunnelRoute/silent) and webpack-related options.
Runtime Sentry initializers apps/docs/sentry.server.config.ts, apps/docs/sentry.edge.config.ts	New server- and edge-targeted Sentry init files calling Sentry.init() with dsn, tracesSampleRate: 1, enableLogs: true, and sendDefaultPii: true.
Client instrumentation apps/docs/src/instrumentation-client.ts	Initialized client-side Sentry and exported onRouterTransitionStart = Sentry.captureRouterTransitionStart.
Shared instrumentation + loader apps/docs/src/instrumentation.ts	New register() that dynamically imports sentry.server.config or sentry.edge.config based on NEXT_RUNTIME; exports onRequestError aliasing Sentry.captureRequestError.
App Router error boundary apps/docs/src/app/global-error.tsx	Added GlobalError client component that calls Sentry.captureException(error) on mount and renders a full-viewport error UI with a "Go to docs" link.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

🚥 Pre-merge checks | ✅ 3 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and specifically identifies the main change: integrating Sentry error tracking/monitoring into the docs application.
Merge Conflict Detection	✅ Passed	✅ No merge conflicts detected when merging into main

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[github-actions]

🍈 Lychee Link Check Report

3660 links: ✅ 2729 OK | 🚫 0 errors | 🔀 265 redirects | 👻 664 excluded

✅ All links are working!

---

Full Statistics Table

Status	Count
✅ Successful	2729
🔀 Redirected	265
👻 Excluded	664
🚫 Errors	0
⛔ Unsupported	2
⏳ Timeouts	0
❓ Unknown	0

[coderabbitai]

Actionable comments posted: 2

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (2)

apps/docs/next.config.mjs (1)

1-55: ⚠️ Potential issue | 🟡 Minor

Fix the trailing backslash typo on line 27; authToken gating is optional.

Your Sentry configuration is well-structured per @sentry/nextjs@10.38.0. A couple of clarifications:

• Line 27 typo: Remove the trailing \ from the comment (CI\ → CI).
• webpack options placement: Your nested webpack: { automaticVercelMonitors, treeshake: ... } is the correct modern location for these options (not mixing buckets). Both automaticVercelMonitors and treeshake.removeDebugLogging are valid here and won't cause issues.
• authToken undefined behavior: When process.env.SENTRY_AUTH_TOKEN is missing in non-CI environments, authToken is simply undefined, and the build proceeds without attempting uploads—no failure. Explicit CI gating (as suggested below) is defensive and good practice, but not strictly required.

Optional defensive CI gating

-  authToken: process.env.SENTRY_AUTH_TOKEN,
+  authToken: process.env.CI ? process.env.SENTRY_AUTH_TOKEN : undefined,

Fix the typo. The authToken suggestion is optional; the rest is correct as-is.

apps/docs/src/instrumentation-client.ts (1)

2-29: ⚠️ Potential issue | 🟠 Major

Lock down Sentry config: env-based DSN, lower sampling rates, and disable PII by default.

The current config poses three real risks on a public docs site:

1. Hardcoded DSN prevents separate environment configs. Preview/staging deployments will send errors to the same production project, polluting signal and making it harder to troubleshoot issues in isolation. Use process.env.NEXT_PUBLIC_SENTRY_DSN instead, so environments can be configured independently.

2. sendDefaultPii: true captures IP addresses, headers, and user-like context by default. This is a privacy concern for a public site—users haven't consented to PII collection by Sentry. The Sentry default is false for good reason. Set it to false unless you have explicit consent and documented need.

3. tracesSampleRate: 1 means 100% of transactions (all page navigation, API calls, etc.) are sent to Sentry. On a docs site with meaningful traffic, this will quickly exceed your quota (5M spans/month on standard plans) and trigger pay-as-you-go overage charges. Production should use a much lower rate (~0.1 = 10% is a common starting point), configurable via env var.

As for enableLogs: true—it's a valid option that pipes console logs into Sentry. There's no inherent problem, but gating it to dev-only (process.env.NODE_ENV !== "production") reduces noise in production events.

Apply this pattern:

Suggested fix

 Sentry.init({
-  dsn: "https://e83ce4699e59051fdeaa330bf4a0dfb9@o4510879743737856.ingest.us.sentry.io/4510879744000000",
+  dsn: process.env.NEXT_PUBLIC_SENTRY_DSN,
 
-  tracesSampleRate: 1,
+  tracesSampleRate:
+    process.env.NODE_ENV === "production"
+      ? Number(process.env.NEXT_PUBLIC_SENTRY_TRACES_SAMPLE_RATE ?? 0.1)
+      : 1,
 
-  enableLogs: true,
+  enableLogs: process.env.NODE_ENV !== "production",
 
-  sendDefaultPii: true,
+  sendDefaultPii: false,
 });

If NEXT_PUBLIC_SENTRY_DSN can be absent in dev/preview, guard the init:

if (process.env.NEXT_PUBLIC_SENTRY_DSN) {
  Sentry.init({ ... });
}

🤖 Fix all issues with AI agents

In `@apps/docs/sentry.edge.config.ts`:
- Around line 1-20: Replace the hardcoded Sentry configuration in Sentry.init:
read dsn from an environment variable (e.g., process.env.SENTRY_DSN) instead of
the literal string, drive tracesSampleRate from an env var with a safe
production default (e.g., parseFloat(process.env.SENTRY_TRACES_SAMPLE_RATE) ||
0.1), set enableLogs based on NODE_ENV (true only in development), and set
sendDefaultPii from an env var defaulting to false (e.g.,
!!JSON.parse(process.env.SENTRY_SEND_DEFAULT_PII || "false")); apply the same
env-driven changes to sentry.server.config.ts so both edge and server configs
use the same safe defaults.

In `@apps/docs/src/app/global-error.tsx`:
- Around line 1-27: Replace the Pages Router-only NextError usage in GlobalError
with a minimal custom error UI and recovery button: inside the GlobalError
component (function GlobalError) remove NextError and render a simple message
and a "Try again" button that calls the reset() function (destructure reset from
the component props) to trigger client-side recovery; when reporting to Sentry
use Sentry.captureException(error) together with Sentry.captureContext (or
Sentry.setContext) to tag the event with error.digest for correlation (ensure
you pass error.digest in the context before captureException) so production logs
can be tied to the UI error digest.

🧹 Nitpick comments (1)

apps/docs/src/instrumentation.ts (1)

1-13: Use else if to clarify mutually exclusive runtime branches.

Since NEXT_RUNTIME is mutually exclusive, switching to else if makes the intent clearer and avoids unnecessary condition checks:

Runtime branch tightening

 export async function register() {
   if (process.env.NEXT_RUNTIME === "nodejs") {
     await import("../sentry.server.config");
-  }
-
-  if (process.env.NEXT_RUNTIME === "edge") {
+  } else if (process.env.NEXT_RUNTIME === "edge") {
     await import("../sentry.edge.config");
   }
 }

The direct assignment of Sentry.captureRequestError to onRequestError is correct and intentional for Next.js 16.1.1 with @sentry/nextjs 10.38.0—Sentry explicitly documents this pattern as the recommended integration approach for error capture in instrumentation files.

asdasdasd