Error Tracking for Quarkus

Quarkus has quietly become the go-to Java microframework for developers building cloud-native applications. Its container-first design, lightning-fast startup times, and minimal memory footprint make it perfect for Kubernetes deployments and serverless functions. But while Spring Boot dominates the error-tracking conversation, Quarkus microservices error tracking remains an overlooked necessity—one that's just as critical when your production system is under load.

Unlike monolithic applications, microservices expose you to distributed failure points: a timeout in one service cascades to others, background jobs fail silently, and errors get swallowed by async handlers. Without proper error tracking, you're flying blind. Quarkus integrates seamlessly with the Sentry SDK, giving you the same observability tooling at a fraction of the complexity.

Setting Up Sentry SDK in Quarkus

Getting error tracking running in a Quarkus app takes minutes. The Sentry Java SDK works with Quarkus out of the box, courtesy of native JSON serialization and minimal reflection overhead.

Start by adding the Maven dependency:

<dependency>
    <groupId>io.sentry</groupId>
    <artifactId>sentry</artifactId>
    <version>7.14.0</version>
</dependency>

Configure it in application.properties:

quarkus.log.handler.sentry.enabled=true
quarkus.log.handler.sentry.dsn=https://<your-key>@light-trace.robomiri.com/1
quarkus.log.handler.sentry.level=WARN
quarkus.log.handler.sentry.in-app-packages=com.mycompany

That's it. Quarkus automatically wires up the Sentry handler to your logging pipeline. Every WARN and ERROR log entry gets shipped to your error-tracking backend. For Sentry-compatible backends like LightTrace, you just swap the DSN.

Capturing Exceptions and Context

Quarkus's CDI (Contexts and Dependency Injection) makes it easy to add error tracking context without littering your code with boilerplate.

Use a JAX-RS exception mapper to catch and report REST errors:

@Provider
public class ErrorExceptionMapper implements ExceptionMapper<Exception> {
    @Override
    public Response toResponse(Exception exception) {
        Sentry.captureException(exception);
        return Response.serverError().entity("Internal Server Error").build();
    }
}

Add rich context that helps you debug. Before reporting an exception, attach custom data:

@ApplicationScoped
public class OrderService {
    public void processOrder(Order order) {
        Sentry.setTag("order_id", String.valueOf(order.getId()));
        Sentry.setTag("customer_tier", order.getCustomer().getTier());
        Sentry.setContext("order", Map.of(
            "amount", order.getTotal(),
            "items_count", order.getItems().size()
        ));
        
        try {
            // process order
        } catch (Exception e) {
            Sentry.captureException(e);
        }
    }
}

When the error lands in your dashboard, you'll see the order ID, customer tier, and transaction amount—far more useful than a bare stack trace.

Quarkus Microservices Error Tracking with Distributed Tracing

The same Sentry SDK you configured for errors also captures distributed traces—and because LightTrace speaks the Sentry protocol directly, you don't need a separate OpenTelemetry pipeline to see them. When a request spans multiple microservices, one trace ID connects the dots.

Turn on performance tracing in application.properties (or sentry.properties):

sentry.dsn=https://<key>@light-trace.robomiri.com/1
sentry.traces-sample-rate=1.0
sentry.environment=production

The Sentry SDK automatically adds a sentry-trace header to outgoing HTTP calls and reads it on the way in, so trace context propagates across services with no extra wiring.

Now, when your order service calls inventory, which calls fulfillment, a single trace ID ties all three spans together. If one service times out, you see exactly where in the chain the failure occurred—response times, database query durations, and HTTP client latency, all visible in a span waterfall.

Performance Monitoring and Transactions

Quarkus applications live and die by throughput and latency. Tracking errors is table stakes; understanding performance is what keeps users happy.

The Sentry SDK automatically instruments HTTP requests as transactions. Mark custom transaction boundaries for business operations:

@ApplicationScoped
public class PaymentService {
    public void processPayment(Payment payment) {
        ITransaction txn = Sentry.startTransaction("process.payment", "payment");
        try {
            // validation, API calls, database writes
            txn.setTag("payment_method", payment.getMethod());
            txn.setMeasurement("processing_time_ms", duration);
        } finally {
            txn.finish();
        }
    }
}

The dashboard then shows transaction p50, p75, p95, and p99 percentiles. If 1% of payments take >5 seconds, you spot it immediately. Pair this with Quarkus's native Micrometer metrics, and you've built a complete performance-monitoring layer.

Handling Background Jobs and Async Work

Quarkus's @Scheduled and Reactive APIs hide errors easily. A failed Panache query in a background task logs nothing; it just silently completes.

Wrap async work with explicit error handling:

@ApplicationScoped
public class NotificationService {
    @Inject
    Mailer mailer;
    
    public Uni<Void> sendNotificationAsync(String email, String message) {
        return Uni.createFrom().item(message)
            .onItem().invoke(msg -> {
                Sentry.captureMessage("Sending notification: " + email);
            })
            .onFailure().invoke(error -> {
                Sentry.captureException(error);
            })
            .chain(() -> mailer.send(email, message));
    }
}

Every failed email send, database timeout, or unexpected exception gets reported before the application moves on. No more discovering at 2am that your notification pipeline has been broken for weeks.

Alert Rules and On-Call Integration

Finding errors is worthless if nobody knows they happened. Set up alert rules to notify your team immediately.

In LightTrace, create a rule like: "Alert when a new error type appears" or "Alert when event frequency exceeds 100 per hour." Delivery is email-based, so your on-call engineer gets a notification in their inbox without configuring Slack webhooks or PagerDuty.

For a Quarkus microservice, typical rules include:

• New OutOfMemoryError (container-sizing problem)
• Spike in database connection timeouts (infrastructure issue)
• Sudden increase in 5xx responses (deployment regression)

Attach the rule to your production release tag, so alerts only fire for real users, not developers testing locally.

Comparing to Spring Boot

Quarkus and Spring Boot error tracking follow the same observability principles—both use the Sentry SDK, both emit metrics to OpenTelemetry. The trade-off is configuration friction: Quarkus requires more explicit setup (you declare OpenTelemetry dependencies, configure endpoints), whereas Spring Boot often works with auto-configuration magic. But once set up, Quarkus is leaner and faster. You're paying a small upfront cost for production efficiency.

Starting Your Error Tracking Journey

Error tracking isn't a luxury for Quarkus teams—it's foundational. The alternative is debugging production failures by grep'ing logs, hoping your infrastructure vendor saved them, or asking customers to reproduce bugs.

The Sentry-compatible LightTrace backend gives you fast, affordable error tracking without the overhead of on-premises Sentry. Add the Maven dependency, set the DSN in your properties file, and start shipping errors. Within minutes, you'll spot issues that were previously invisible.

When you're ready to scale, you'll have months of error history, transaction metrics, and release health data that would have been lost on a logging server.