What Is Sentry.io? Error and Performance Monitoring for Next.js and Nest.js

Once an application goes live, the hard part is rarely writing the code. It's understanding what is happening while the app runs. When a user says "the page won't load," we want to know which request failed, in which browser, in which release, and with what data. sentry.io is an error and performance monitoring platform built to close exactly this gap. In this post, I'll explain what Sentry is, which features it offers, which projects it fits and for what purpose, and how it's set up on the Next.js and Nest.js side.

What is Sentry.io?

Sentry is an observability platform that collects errors and performance issues from your application, organizes them, and delivers them to your development team in a meaningful way. A small SDK is added to your application. When an exception is thrown, a promise is rejected, or a performance measurement you've defined completes, the SDK generates an event and sends it to Sentry's servers. On the Sentry side, these events are grouped, placed on a timeline, and delivered to the relevant people as notifications.

Sentry has an open-source core and can also be run on your own server (self-hosted). Most teams, however, prefer the cloud version. Whichever route you choose, the integration on the application side is largely the same.

What problem does Sentry solve?

Before Sentry, error tracking usually happened through three channels: user support requests, server log files, and console output noticed by chance. The problems with this approach are well known:

• Users can't accurately describe what went wrong.
• Log files often lack context, and the same error gets lost among thousands of lines.
• Frontend errors never show up in server logs.
• Nobody knows when an error first started, which release introduced it, or how many users it affected.

Sentry changes this picture. When an error occurs, you have the following information: the stack trace, the file and line where it happened, request details, breadcrumb records showing the user's steps leading up to the error, browser or operating system information, the application version, and how many times the error repeated. With this context, you can largely understand an error before trying to reproduce it.

Core concepts

A few key terms make working with Sentry much easier:

• DSN (Data Source Name): The address that determines which project the SDK sends its events to. It shouldn't be treated as a secret, but storing it as an environment variable is still good practice.
• Event: A single error or measurement record.
• Issue: A parent record formed by grouping similar events. Even if the same error is triggered hundreds of times, it's collected under a single issue.
• Stack trace: A record showing the call chain that led to the error.
• Breadcrumb: A trail of events that happened before an error, such as clicks, HTTP requests, and console messages.
• Source map: A file that maps minified JavaScript code's stack traces back to the original source code. In production builds, it's one of the most critical pieces for making errors meaningful.
• Environment and release: Lets you distinguish which environment (production, staging) and which application version events came from.
• Fingerprint and grouping: Determines the rules by which events are grouped. Custom rules can be written when needed.

Sentry's core features

Sentry's features have expanded over time. In practice, the most commonly used are these:

Error Monitoring

Tracking of uncaught exceptions and errors you report manually. It supports processes such as the issue list, prioritization, assignment, marking as resolved, and reopening on regression.

Performance Monitoring (Tracing)

Monitors requests, database queries, external API calls, and frontend page loads. It lets you see which endpoint is slow and where the slowness occurs (network, database, application code). In distributed systems, it can also join traces across services.

Session Replay

Lets you replay a user's browser session in a video-like format. Because masking sensitive fields is critical, you need to configure privacy settings carefully before enabling this feature.

Profiling

Collects data such as CPU usage and function-level execution time, helping to identify performance bottlenecks at the code level.

Cron Monitoring and Uptime

Tracks whether scheduled jobs (cron jobs) run, and whether they take longer than expected. It can also be used to monitor the availability of specific services.

Alerts and workflows

When specific conditions occur (for example, when a new issue opens or an error crosses a defined threshold), you can send notifications to email, Slack, Microsoft Teams, or similar channels. Setting up notification rules well is the most effective way to reduce noise.

Release tracking and health metrics

When you ship a new release, you can compare whether the error rate went up or down. Monitoring after deployment is therefore very valuable.

Which projects use it, and for what purpose?

Sentry is useful in all kinds of software projects, but the focus differs from project to project.

Next.js applications

Next.js runs both on the client side (React components, browser events) and on the server side (Server Components, Route Handlers, Server Actions, middleware). Because of this, it can be hard to tell where an error originated. Sentry's Next.js integration makes this distinction automatically and shows events together with both client and server context. It's especially useful for:

• Monitoring page load performance and Core Web Vitals metrics
• Catching Server Component and Server Action errors
• Getting meaningful stack traces in compiled code through source map uploads
• Detecting hydration errors and client-side crashes

Nest.js APIs

In backend services written with Nest.js, Sentry is mostly used to catch exceptions at the HTTP layer, monitor database query performance, and track background jobs (queues, cron). Thanks to the modular architecture, it's possible to enable Sentry from a central point through exception filters and interceptors.

Single-page applications (React, Vue, Angular)

The biggest problem with client-side applications is that their errors don't appear in server logs. Sentry's browser SDK records uncaught errors, rejected promises, and console events. Combined with release information, you can clearly see which deployment introduced which error.

Mobile applications

SDKs are available for React Native, Flutter, iOS, and Android. They're useful for crash reports, app startup time, and network requests. On mobile, uploading symbol files (dSYM, ProGuard mapping) is important.

Background jobs and data pipelines

Queue consumers, scheduled tasks, and ETL processes can fail silently. Sentry's cron monitoring and manual error reporting make these kinds of jobs visible.

Team and operations side

For IT teams, Sentry is a tool for operations as well as for developers. Alert rules and the assignment mechanism make it clear which team owns which error. This also helps you manage on-call processes more healthily.

Setting up a Next.js project

Sentry's official package for Next.js is @sentry/nextjs. The wizard command creates most of the required files for you:

npx @sentry/wizard@latest -i nextjs

After installation, your project typically contains the following configuration. The basic client-side setting:

import * as Sentry from '@sentry/nextjs';

Sentry.init({
  dsn: process.env.NEXT_PUBLIC_SENTRY_DSN,
  environment: process.env.NODE_ENV,
  tracesSampleRate: 0.1,
});

The instrumentation.ts file is used for the server and Edge environments. In recent versions of Next.js, the onRequestError hook can also be exported from this file to automatically catch errors that occur in server-side requests:

import * as Sentry from '@sentry/nextjs';

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');
  }
}

export const onRequestError = Sentry.captureRequestError;

Here, you need to pay attention to the tracesSampleRate value. Tracing every request is inefficient in terms of both cost and noise. In production, it's generally a reasonable approach to start with a low rate (for example, 0.1) and adjust it as needed.

Uploading source maps requires an authentication token during the build process. Never commit this token to your repository; store it in the secret variables of your CI/CD environment.

Setting up a Nest.js project

For Nest.js, the current approach is the @sentry/nestjs package. Sentry must be initialized before the application modules are loaded. For this reason, a separate instrument.ts file is usually created and imported at the very top of main.ts:

// instrument.ts
import * as Sentry from '@sentry/nestjs';

Sentry.init({
  dsn: process.env.SENTRY_DSN,
  environment: process.env.NODE_ENV,
  tracesSampleRate: 0.1,
});

// main.ts
import './instrument';
import { NestFactory } from '@nestjs/core';
import { AppModule } from './app.module';

async function bootstrap() {
  const app = await NestFactory.create(AppModule);
  await app.listen(3000);
}
bootstrap();

Order matters. If modules are loaded before Sentry is initialized, errors in them and automatic instrumentation may not work properly. Then, to combine Nest's global exception filter with Sentry, you can add the SentryGlobalFilter provider to your application. This way, uncaught HTTP exceptions are forwarded to Sentry.

For critical flows where you want to add context manually, using captureException directly makes sense:

import * as Sentry from '@sentry/nestjs';

try {
  await this.paymentService.charge(order);
} catch (err) {
  Sentry.captureException(err, {
    tags: { module: 'payment' },
    extra: { orderId: order.id },
  });
  throw err;
}

Here, the tags and extra fields are valuable for filtering issues and understanding an event's context. However, add only the information you actually need.

Privacy and data management

Every event sent to Sentry carries a piece of your application. For this reason, you need to be careful about data management:

• Passwords, session tokens, card details, and personal data should never leak into events. Sentry's default scrubbing rules are a starting point, but they may not be enough.
• Options such as sendDefaultPii should be deliberately turned on or off according to your application's data processing policy.
• With the beforeSend hook, you can clean or filter events before they are sent.
• If you use Session Replay, be sure to review your text and media masking settings.
• Manage role-based access so that you control who on your team can access which project.

For applications subject to regulations such as KVKK (Turkey's data protection law) and GDPR, topics like Sentry's data storage region and its data processing agreement should also be evaluated. These decisions should be made together with your legal and security teams.

Cost and sampling

Sentry's pricing depends on the volume of events and monitoring data (traces, replays, profiles) processed. For current plans and quotas, I recommend checking the official pricing page, since details can change over time. There are a few practical ways to keep costs under control:

• Keep the tracesSampleRate low in production, and define higher rates for critical endpoints.
• Filter out known and harmless errors (for example, noise coming from browser extensions) with ignoreErrors.
• Keep issues tidy with grouping rules so that repeated events of the same error are easy to follow.
• Use a separate project and a lower sampling rate for the staging environment.

Common mistakes

These are typical problems encountered after Sentry is put into use:

• Source maps not uploaded: Stack traces remain with minified line and column numbers. You need to add the source map upload step to your CI/CD pipeline during the build.
• Missing release information: You can't answer the question of which release introduced an error. It's important to generate the release value automatically on every deployment.
• Noise: Alerting on every error eventually leads to notifications being completely ignored. Separate alert rules by severity.
• Wrong environment separation: Development errors getting mixed into the production issue list. Always define the environment value correctly.
• Sensitive data leaks: Skipping the data scrubbing settings described above.
• Initialization order: In Nest.js, not importing the instrument.ts file at the very top, or in Next.js, not loading configuration files according to the environment.

Sentry's alternatives

Sentry isn't the only option. Error tracking tools such as Bugfender, Rollbar, and Bugsnag; full-stack observability platforms such as Datadog, New Relic, and the Grafana ecosystem; and your own infrastructure built on the OpenTelemetry standard are all alternatives. Which tool you choose depends on team size, budget, data privacy requirements, and existing infrastructure. For small and mid-sized teams, Sentry's quick setup and developer-focused interface often stand out. For large enterprise systems, platforms that bring logs, metrics, and traces together under one roof may be a better fit.

Conclusion

Sentry.io is a mature and easy-to-use tool for making your application's behavior in production visible. With Next.js, you can monitor client-side and server-side issues together, and with Nest.js, you can clearly see errors and performance bottlenecks in the API layer. What matters most is not just installing the tool, but establishing a consistent process with the right sampling, meaningful alert rules, and privacy settings.

If you'd like support with setting up Sentry in your own project, designing a monitoring strategy, or improving the observability of an existing system, feel free to get in touch.