Sentry is an error tracking and performance monitoring platform.
While logging is typically used to record routine application activity, Sentry is designed to capture exceptions, request failures, performance traces, and other diagnostic information that helps explain why something went wrong.
When an instrumented error occurs, Sentry records the stack trace, request context, runtime information, and other metadata needed to investigate the problem.
Oolvay includes first-class Sentry support across the browser, server runtime, and edge runtime. The integration is completely optional and follows the same Bring Your Own Keys philosophy as the rest of the observability stack.
When disabled, Sentry does not initialize in the browser, server runtime, or edge runtime, and no events are sent to Sentry.
Once initialized, Sentry can automatically capture three categories of telemetry:
The primary exception is a handled error. If an exception is caught inside a try/catch block, or if your application returns an error state instead of throwing an exception, Sentry will not receive it unless you report it explicitly.
Sentry is initialized separately for each runtime:
| File | Runtime |
|---|---|
instrumentation-client.ts | Browser |
sentry.server.config.ts | Node.js |
sentry.edge.config.ts | Edge |
The instrumentation.ts file loads the correct configuration automatically based on the current runtime.
0 / 2,000 characters
export async function register() {
if (process.env.NEXT_RUNTIME === "nodejs") {
await import("./sentry.server.config")
}
if (process.env.NEXT_RUNTIME === "edge") {
await import("./sentry.edge.config")
}
}This allows a single Sentry project to receive telemetry from browser code, API routes, server actions, and edge functions through a unified dashboard.
Create an account at https://sentry.io if you do not already have one.
Find your organization slug.
In the Sentry dashboard:
The value shown in that field is your organization name. Add it to your environment variables:
SENTRY_ORG=Create or locate your Sentry project. In the Sentry dashboard:
The project slug becomes your project name. Add it to your environment variables:
SENTRY_PROJECT=Create an auth token. In the Sentry dashboard:
Add it to your environment variables:
SENTRY_AUTH_TOKEN=sentrys_***Obtain your DSN. In the Sentry dashboard:
This DSN then goes into your environment variables:
NEXT_PUBLIC_SENTRY_DSN=https://...At this point you should have these values in your .env.local:
NEXT_PUBLIC_SENTRY_DSN=https://...
SENTRY_ORG=
SENTRY_PROJECT=
SENTRY_AUTH_TOKEN=sentrys_***Enable Sentry in config/site.ts.
observability: {
errorTracking: {
enabled: true,
},
},Restart your development server.
bun devSentry configuration is loaded during application startup. Changes to environment variables will not be picked up until the server restarts.
Sentry uses two independent configuration layers.
The following settings enable error tracking, Session Replay, and performance monitoring:
NEXT_PUBLIC_SENTRY_DSN=observability: {
errorTracking: {
enabled: true,
},
},These settings control whether Sentry initializes in the browser, server runtime, and edge runtime.
Without them, Sentry does not initialize and no events are sent to Sentry.
The following environment variables enable source map uploads and release management during production builds:
SENTRY_ORG=
SENTRY_PROJECT=
SENTRY_AUTH_TOKEN=These variables are used by the Sentry webpack plugin configured in next.config.ts.
Sentry can report errors even if these variables are not configured. Their purpose is to improve the quality of error reports by uploading source maps and release metadata during production builds. Without source map uploads, production stack traces may be difficult to read because Sentry cannot map minified JavaScript bundles back to the original source files in your application.
All Sentry settings live in config/site.ts.
observability: {
errorTracking: {
enabled: true,
tracesSampleRate: 1.0,
replaysSessionSampleRate: 0.1,
replaysOnErrorSampleRate: 1.0,
sendDefaultPii: true,
},
},We have already covered the enabled field. The tracesSampleRate, replaysSessionSampleRate, and replaysOnErrorSampleRate fields accept values expressed as fractions of 1.
Controls how much performance monitoring data is collected.
| Value | Meaning |
|---|---|
1.0 | Capture 100% of traces |
0.5 | Capture 50% of traces |
0.1 | Capture 10% of traces |
Performance tracing is most valuable on routes where latency directly affects user experience or revenue. Business-critical workflows often benefit from higher sampling rates, while stable, low-risk routes can usually be sampled more conservatively.
Most production applications can start with 0.1 and temporarily increase the value while investigating a performance issue.
Controls how many user sessions are recorded with Session Replay.
| Value | Meaning |
|---|---|
1.0 | Record 100% of sessions |
0.5 | Record 50% of sessions |
0.1 | Record 10% of sessions |
Session Replay is most valuable when understanding user behavior is just as important as understanding the error itself. Higher sampling rates provide more recordings to investigate, while lower sampling rates reduce storage usage and replay volume.
Most production applications operate comfortably between 0.01 and 0.1.
Controls replay capture when an error occurs.
| Value | Meaning |
|---|---|
1.0 | Record replay data for 100% of sessions with errors |
0.5 | Record replay data for 50% of sessions with errors |
0.1 | Record replay data for 10% of sessions with errors |
In most applications, this value should remain 1.0.
When a user encounters an error, the replay often provides the fastest path to understanding what happened. Lowering this value reduces replay usage but also increases the chance that the exact session needed to diagnose a production issue will be missing. Only consider lowering this value if replay volume is creating significant quota pressure.
Controls whether user-identifying information is included in events sent to Sentry.
When enabled, Sentry may include information such as IP addresses, authenticated user identifiers, and request metadata in error reports.
This additional context often makes production issues significantly easier to diagnose and is suitable for most applications.
Consider disabling it if your privacy, compliance, or data-handling requirements prohibit sending personal identifiers to third-party services.
Session Replay records user interactions leading up to an error.
Instead of only seeing a stack trace, you can watch the sequence of actions that triggered the failure.
This is particularly useful for:
Replay support is configured automatically in instrumentation-client.ts.
No additional setup is required.
When your application is deployed, JavaScript and React bundles are optimized and minified.
Without source maps, a production error may point to a generated file and line number that is difficult to interpret.
With source maps uploaded, Sentry can map production stack traces back to the original source files in your application.
Oolvay uploads source maps automatically when SENTRY_ORG, SENTRY_PROJECT, and SENTRY_AUTH_TOKEN are configured.
Sentry can measure the performance of your application in addition to capturing errors.
Examples include:
Performance data is controlled by tracesSampleRate.
Higher sampling rates provide more visibility but consume more Sentry quota.
Unhandled exceptions are captured automatically by the Sentry SDK.
Handled exceptions must be reported manually because your application has already intercepted the error.
import * as Sentry from "@sentry/nextjs"
try {
await doSomethingRisky()
} catch (error) {
Sentry.captureException(error)
return {
success: false,
error: "Something went wrong.",
}
}Any time you intentionally catch an exception but still want visibility into it, call Sentry.captureException().
For production applications, it is often useful to attach additional context to an error before sending it to Sentry. We do this using Sentry.withScope():
Sentry.withScope((scope) => {
scope.setTag("action", "createSSOProvider")
scope.setTag("type", "server-action")
scope.setContext("sso", {
provider: input.provider,
domain: input.domain,
})
Sentry.captureException(error)
})Context such as action names, request identifiers, user IDs, and business-specific metadata can make production issues significantly easier to investigate.
The most commonly used metadata types are:
Fingerprints control how Sentry groups events into issues.
scope.setFingerprint(["admin", "createSSOProvider"])Use fingerprints when many occurrences of the same logical failure should appear as a single issue in Sentry instead of being fragmented across multiple issues.
Tags make issues easier to search, filter, and segment.
scope.setTag("action", "createSSOProvider")
scope.setTag("type", "server-action")These are useful for categorizing events by feature, route, action, environment, or business workflow.
Context attaches structured diagnostic information to an event.
scope.setContext("sso", {
provider: input.provider,
domain: input.domain,
})Use context for business-specific details that help explain what the application was doing when the error occurred.
Oolvay assigns every request a unique request ID and commonly attaches it to Sentry events.
scope.setTag("request_id", requestId)This allows Sentry issues to be correlated with application logs, making production investigations significantly faster.
Attaching request IDs, tags, fingerprints, and structured context to server-side exceptions helps correlate errors with logs and groups them more effectively inside Sentry.
Sentry traffic is routed through the /monitoring endpoint rather than connecting directly to Sentry from the browser.
This improves reliability in environments where browser extensions, ad blockers, privacy tools, or network policies block direct communication with known telemetry domains.
The route is automatically registered as a public route so authentication middleware does not interfere with event delivery.
You do not need to interact with this endpoint directly.
errorTracking: {
enabled: true,
tracesSampleRate: 1.0,
replaysSessionSampleRate: 1.0,
replaysOnErrorSampleRate: 1.0,
}Capturing everything makes debugging easier while development traffic remains low.
errorTracking: {
enabled: true,
tracesSampleRate: 0.1,
replaysSessionSampleRate: 0.05,
replaysOnErrorSampleRate: 1.0,
}These values provide good visibility while keeping Sentry usage under control for most applications.
Set enabled to false in config/site.ts to prevent the Sentry SDK from initializing.
observability: {
errorTracking: {
enabled: false,
},
},When disabled:
Removing NEXT_PUBLIC_SENTRY_DSN is also recommended when Sentry is not being used.
Confirm all of the following:
NEXT_PUBLIC_SENTRY_DSN is present in .env.localenabled: true is set in config/site.tsVerify that replay sampling is enabled.
replaysSessionSampleRate: 0.1or
replaysOnErrorSampleRate: 1.0If both values are 0, no replay data will be recorded.
Sentry requires the following entries in the connect-src directive of your Content Security Policy:
"https://*.sentry.io",
"https://*.ingest.sentry.io",
"https://*.ingest.us.sentry.io",The default Oolvay CSP already includes the required Sentry domains. If you customized the policy, verify that the Sentry origins are still present.
Verify that all of the following variables are configured:
SENTRY_ORGSENTRY_PROJECTSENTRY_AUTH_TOKENThese values allow Oolvay to upload source maps during the build process so Sentry can map production errors back to the original source files.
Handled exceptions are not reported automatically.
If an error is caught inside a try/catch block, call Sentry.captureException() manually before handling the failure.
Sentry complements logging rather than replacing it. Logs help explain what your application was doing. Sentry helps surface failures that require investigation.