Monitoring the Error Rate of a Spring Boot Web Application

Table Of Contents

In my previous blog posts about creating monitoring metrics with Dropwizard Metrics and exposing them for the Prometheus monitoring application we already have gained a little insight into why monitoring is important and how to implement it.

However, we have not looked into monitoring specific and meaningful metrics yet. For one such metric, the error rate, I would like to go into a little detail in this blog post. The error rate is important for any kind of application that processes requests of some sort. Some applications, like GitHub, even publicly display their error rate to show that they are able to handle the load created by the users (have a look at the ‘Exception Percentage’ on their status page).

The error rate is a good indicator for the health of a system since the occurrence of errors most certainly indicates something is wrong. But what exactly is the definition of error rate and how can we measure it in a Spring Boot application?

Definitions of “Error Rate”

For the definition of our application’s error rate we can borrow from Wikipedia’s definition of bit error rate:

The bit error rate (BER) is the number of bit errors per time unit.

Although our application sends and receives bits, the bit error rate is a little too low-level for us. Transferring that definition to the application level however, we come up with something like this:

The application error rate is the number of requests that result in an error per time unit.

It may also be interesting to measure errors in percentage instead of time units, so for the sake of this blog post, we add another definition:

The application error percentage is the number of requests that result in an error compared to the total number of requests.

For our Spring Boot application “resulting in an error” means that some kind of internal error was caused that prevented the request from being processed successfully (i.e. HTTP status 5xx).

Counting Errors

Using Spring MVC, counting errors in an application is as easy as creating a central exception handler using the @ControllerAdvice annotation:

public class ControllerExceptionHandler {

  private MetricRegistry metricRegistry;

  public ControllerExceptionHandler(MetricRegistry metricRegistry){
    this.metricRegistry = metricRegistry;
  @ResponseStatus(value = HttpStatus.INTERNAL_SERVER_ERROR)
  public String handleInternalError(Exception e) {
    logger.error("Returned HTTP Status 500 due to the following exception:", e);
    return "Internal Server Error";
  private void countHttpStatus(HttpStatus status){
    Meter meter = metricRegistry.meter(String.format("http.status.%d", status.value()));

In this example, we’re catching all Exceptions that are not caught by any other exception handler and increment a Dropwizard meter called http.status.500 (refer to my previous blog post to learn how to use Dropwizard Metrics).

Counting Total Requests

In order to calculate the error percentage, we also want to count the total number of HTTP requests processed by our application. One way to do this is by implementing a WebMvcConfigurerAdapter and registering it within our ApplicationContext like this:

public class RequestCountMonitoringConfiguration extends WebMvcConfigurerAdapter {

  private Meter requestMeter;

  public RequestCountMonitoringConfiguration(MetricRegistry metricRegistry) {
    this.requestMeter = metricRegistry.meter("http.requests");

  public void addInterceptors(InterceptorRegistry registry) {
    registry.addInterceptor(new HandlerInterceptorAdapter() {
      public void afterCompletion(HttpServletRequest request,
          HttpServletResponse response, Object handler, Exception ex)
          throws Exception {

This will intercept all incoming requests and increment a Meter called http.requests after the request has been processed, regardless of an exception being thrown or not.

Monitoring the Error Rate with Prometheus

If we translate the Dropwizard metrics into the Prometheus data format (see my previous blog post), we will see the following metrics when typing “/prometheus” into the browser:

http_requests_total 13.0
http_status_500_total 4.0

Now, we have a prometheus metric called http_status_500_total that counts unexpected errors within our application and a metric called http_requests_total that counts the total number of processed requests.

Setting up Prometheus

Once Prometheus is setup we can play around with these metrics using Prometheus' querying language.

To set up Prometheus, simply install it and edit the file prometheus.yml to add your application’s url to targets and add metrics_path: '/prometheus' if your application’s prometheus metrics are exposed via the /prometheus endpoint. Once started, you can access the Prometheus web interface via localhost:9090 by default.

Querying Metrics in Prometheus' Web Interface

In the web interface, you can now provide a query and press the “execute” button to show a graph of the metrics you queried.

To get the average rate of errors per second within the last minute, we can use the rate() function like this:

rate(http_status_500_total [1m])

Likewise we can query the average rate of total requests per second:

rate(http_http_requests_total [1m])

And finally, we can relate both metrics by calculating the percentage of erroneously processed requests within the last minute

rate(http_status_500_total [1m]) / rate(http_requests_total [1m])

The result of the last query looked something like this in the Prometheus web interface, once I manually created some successful requests and some errors:

![Error Percentage]({{ base }}/assets/img/posts/error_percentage.png)


By simply counting all requests and counting those requests that return an HTTP status 500 (internal server error) and exposing those counters via Dropwizard Metrics we can set up a monitoring with Prometheus that alerts us when the application starts creating errors for some reason. Though pretty easy to calculate, the error rate is a very meaningful indicator of our application’s health at any time and should be present in every monitoring setup.

Written By:

Tom Hombergs

Written By:

Tom Hombergs

As a professional software engineer, consultant, architect, general problem solver, I've been practicing the software craft for more than fifteen years and I'm still learning something new every day. I love sharing the things I learned, so you (and future me) can get a head start. That's why I founded

Recent Posts

Creating and Publishing an NPM Package with Automated Versioning and Deployment

In this step-by-step guide, we’ll create, publish, and manage an NPM package using TypeScript for better code readability and scalability. We’ll write test cases with Jest and automate our NPM package versioning and publishing process using Changesets and GitHub Actions.

Read more

Offloading File Transfers with Amazon S3 Presigned URLs in Spring Boot

When building web applications that involve file uploads or downloads, a common approach is to have the files pass through an application server.

Read more

One Stop Guide to Java Functional Interfaces

Introduction to Functional Programming Functional programming is a paradigm that focuses on the use of functions to create clear and concise code.

Read more