Spring Boot Error Tracking Setup

Spring Boot applications run critical business logic — payment processing, order fulfillment, user authentication — often far from a developer's monitoring view. When something breaks in production, you need to know immediately, not when a customer calls. Spring Boot error tracking with the Sentry SDK gives you that visibility: every uncaught exception, every MVC error, and every failed operation lands in a dashboard with full stack traces, request context, and user information.

This guide walks through adding production-grade error tracking to any Spring Boot application, built on the same pattern as adding error tracking to any app. By the end, you'll capture exceptions automatically, enrich them with meaningful context, and be alerted the moment something new goes wrong.

Install and initialize the Sentry SDK

Start by adding the Sentry Spring Boot starter to your dependencies. If you're using Maven:

<dependency>
  <groupId>io.sentry</groupId>
  <artifactId>sentry-spring-boot-starter</artifactId>
  <version>7.13.0</version>
</dependency>

Or with Gradle:

implementation 'io.sentry:sentry-spring-boot-starter:7.13.0'

Next, configure the SDK in your application.properties or application.yml. Because LightTrace speaks the Sentry protocol, you point the standard Sentry SDK at LightTrace by setting only the DSN:

sentry.dsn=https://<key>@your-lighttrace-host/1
sentry.environment=production
sentry.release=api@1.2.3
sentry.traces-sample-rate=1.0
sentry.enable-tracing=true

The starter automatically integrates with Spring's exception handling, so uncaught exceptions are captured without any additional boilerplate. If you need programmatic initialization, use:

import io.sentry.spring.boot.SentrySpringBootAutoConfiguration;

@SpringBootApplication
public class Application {
  public static void main(String[] args) {
    SpringApplication.run(Application.class, args);
  }
}

The auto-configuration handles everything—error tracking, distributed tracing setup, and breadcrumb collection from Spring's logging framework.

Spring Boot error tracking: capture exceptions and MVC errors

The Sentry starter ships two key pieces: an exception resolver that catches unhandled controller exceptions, and a servlet filter that logs breadcrumbs for every HTTP request.

If you have a REST controller that throws an exception, it's automatically reported:

@RestController
@RequestMapping("/api/orders")
public class OrderController {

  @PostMapping
  public Order createOrder(@RequestBody OrderRequest req) {
    // If userService.getUser throws, it's captured automatically
    User user = userService.getUser(req.userId);
    Order order = orderService.create(user, req);
    return order;
  }
}

The SDK captures the stack trace, the HTTP request (method, URL, headers, body), the affected user, and the release version. In your LightTrace dashboard, you'll see the error grouped as a single issue with all occurrences linked.

For exceptions you expect but want to track anyway, use:

import io.sentry.Sentry;

try {
  paymentGateway.charge(user, amount);
} catch (PaymentException e) {
  Sentry.captureException(e);
  // handle gracefully
}

Add request and user context

Raw stack traces are a start, but the real speed-up comes from context. Set the affected user early—usually after login—so every error is tied to the person who hit it:

import io.sentry.Sentry;

@PostMapping("/login")
public LoginResponse login(@RequestBody LoginRequest req) {
  User user = authService.authenticate(req.email, req.password);
  Sentry.setUser(new UserFeedback(
    user.getId(),
    user.getEmail(),
    null,
    user.getUsername()
  ));
  return new LoginResponse(user);
}

Breadcrumbs record the events leading up to an error. The Sentry starter automatically collects HTTP requests and logs, but you can add domain-specific breadcrumbs:

Sentry.addBreadcrumb(new Breadcrumb() {{
  setCategory("checkout");
  setMessage("User clicked place order");
  setLevel(SentryLevel.INFO);
}});

When an error occurs later in the same request, you'll see the exact breadcrumb trail that led to it—far faster than scrolling through logs.

Tag releases and environments

One of the highest-impact debugging tools is knowing which release introduced a regression. Tag every event with your version:

sentry.release=api@1.2.3

Then, in your deployment pipeline, after releasing a new version, you can query: "How many new issues appeared after 1.2.3?" This is release health monitoring — the ability to correlate errors to the exact deploy that introduced them.

Similarly, set the environment so you don't accidentally mix production errors with staging noise:

sentry.environment=production
sentry.profiles.active[0]=prod

If you have multiple Spring profiles (dev, staging, prod), initialize Sentry only for production:

@Configuration
@ConditionalOnProperty(name = "spring.profiles.active", havingValue = "prod")
public class SentryConfig {
  // Sentry is auto-configured by the starter; just be explicit about profiles
}

Set up alerts and monitoring

Once errors are being captured, configure alerts in the LightTrace dashboard. The two most useful alert rules are:

1. New issue — notify your team the moment a previously unseen error appears. This catches regressions fast.
2. Frequency threshold — if an existing issue spikes to, say, 100 events in 5 minutes, page someone. This catches the early signs of a widespread problem.

Alerts are delivered by email, so wire them to a team alias or on-call rotation. See how to set up error alerts for the full walkthrough.

For microservices or distributed systems, distributed tracing lets you follow a request across services and pinpoint which one is slow or failing. Enable it with the same DSN and traces-sample-rate, and LightTrace will stitch together spans from all your services.

Common Java errors to watch for

A few Java errors show up repeatedly in production Spring Boot apps:

• NullPointerException — the classic "forgot a null check." Readable stack traces with LightTrace make it obvious which line.
• JsonMappingException — usually a schema mismatch between client and server. Check your DTOs and version your API contracts.
• DataAccessException — a database error bubbled up. Often means a query timeout, a deadlock, or a connection pool exhaustion.

Each of these lands in your dashboard with the request that triggered it, the user affected, and the exact line in your code. With how to read a stack trace, you can go from "something is broken" to "here's the fix" in minutes instead of hours.

That's the full setup: the starter configured with your LightTrace DSN, request and user context attached, releases tagged, and alerts configured. Your Spring Boot app is now wired for visibility. The next production error becomes a line in your dashboard instead of a support ticket or a 3 a.m. page.