40. Endpoints

Actuator endpoints allow you to monitor and interact with your application. Spring Boot includes a number of built-in endpoints and you can also add your own. For example the health endpoint provides basic application health information.

The way that endpoints are exposed will depend on the type of technology that you choose. Most applications choose HTTP monitoring, where the ID of the endpoint is mapped to a URL. For example, by default, the health endpoint will be mapped to /health.

The following endpoints are available:



Displays an auto-configuration report showing all auto-configuration candidates and the reason why they ‘were’ or ‘were not’ applied.



Displays a complete list of all the Spring Beans in your application.



Displays a collated list of all @ConfigurationProperties.



Performs a thread dump.



Exposes properties from Spring’s ConfigurableEnvironment.



Shows application health information (a simple ‘status’ when accessed over an unauthenticated connection or full message details when authenticated).



Displays arbitrary application info.



Shows ‘metrics’ information for the current application.



Displays a collated list of all @RequestMapping paths.



Allows the application to be gracefully shutdown (not enabled by default).



Displays trace information (by default the last few HTTP requests).



Depending on how an endpoint is exposed, the sensitive parameter may be used as a security hint. For example, sensitive endpoints will require a username/password when they are accessed over HTTP (or simply disabled if web security is not enabled).

40.1 Customizing endpoints

Endpoints can be customized using Spring properties. You can change if an endpoint is enabled, if it is considered sensitive and even its id.

For example, here is an application.properties that changes the sensitivity and id of the beans endpoint and also enables shutdown.


The prefix ‟endpoints + . + name” is used to uniquely identify the endpoint that is being configured.

By default, all endpoints except for shutdown are enabled. If you prefer to specifically “opt-in” endpoint enablement you can use the endpoints.enabled property. For example, the following will disable all endpoints except for info:


40.2 Health information

Health information can be used to check the status of your running application. It is often used by monitoring software to alert someone if a production system goes down. The default information exposed by the health endpoint depends on how it is accessed. For an insecure unauthenticated connection a simple ‘status’ message is returned, for a secure or authenticated connection additional details are also displayed (see Section 41.6, “HTTP Health endpoint access restrictions” for HTTP details).

Health information is collected from all HealthIndicator beans defined in your ApplicationContext. Spring Boot includes a number of auto-configured HealthIndicators and you can also write your own.

40.3 Security with HealthIndicators

Information returned by HealthIndicators is often somewhat sensitive in nature. For example, you probably don’t want to publish details of your database server to the world. For this reason, by default, only the health status is exposed over an unauthenticated HTTP connection. If you are happy for complete health information to always be exposed you can set endpoints.health.sensitive to false.

Health responses are also cached to prevent “denial of service” attacks. Use the endpoints.health.time-to-live property if you want to change the default cache period of 1000 milliseconds.

40.3.1 Auto-configured HealthIndicators

The following HealthIndicators are auto-configured by Spring Boot when appropriate:



Checks for low disk space.


Checks that a connection to DataSource can be obtained.


Checks that a Mongo database is up.


Checks that a Rabbit server is up.


Checks that a Redis server is up.


Checks that a Solr server is up.

40.3.2 Writing custom HealthIndicators

To provide custom health information you can register Spring beans that implement the HealthIndicator interface. You need to provide an implementation of the health() method and return a Health response. The Health response should include a status and can optionally include additional details to be displayed.

import org.springframework.boot.actuate.health.HealthIndicator;
import org.springframework.stereotype.Component;

public class MyHealth implements HealthIndicator {

    public Health health() {
        int errorCode = check(); // perform some specific health check
        if (errorCode != 0) {
            return Health.down().withDetail("Error Code", errorCode).build();
        return Health.up().build();


In addition to Spring Boot’s predefined Status types, it is also possible for Health to return a custom Status that represents a new system state. In such cases a custom implementation of the HealthAggregator interface also needs to be provided, or the default implementation has to be configured using the management.health.status.order configuration property.

For example, assuming a new Status with code FATAL is being used in one of your HealthIndicator implementations. To configure the severity order add the following to your application properties:

management.health.status.order: DOWN, OUT_OF_SERVICE, UNKNOWN, UP

You might also want to register custom status mappings with the HealthMvcEndpoint if you access the health endpoint over HTTP. For example you could map FATAL to HttpStatus.SERVICE_UNAVAILABLE.

40.4 Custom application info information

You can customize the data exposed by the info endpoint by setting info.* Spring properties. All Environment properties under the info key will be automatically exposed. For example, you could add the following to your application.properties:

info.app.description=My awesome service

40.4.1 Automatically expand info properties at build time

Rather than hardcoding some properties that are also specified in your project’s build configuration, you can automatically expand info properties using the existing build configuration instead. This is possible in both Maven and Gradle.

Automatic property expansion using Maven

You can automatically expand info properties from the Maven project using resource filtering. If you use the spring-boot-starter-parent you can then refer to your Maven ‘project properties’ via @..@ placeholders, e.g.

project.description=Demo project for info endpoint
info.build.artifact[email protected]@
info.build.name[email protected]@
info.build.description[email protected]@
info.build.version[email protected]@

In the above example we used project.* to set some values to be used as fallbacks if the Maven resource filtering has not been switched on for some reason.


The spring-boot:run maven goal adds src/main/resources directly to the classpath (for hot reloading purposes). This circumvents the resource filtering and this feature. You can use the exec:java goal instead or customize the plugin’s configuration, see the plugin usage page for more details.

If you don’t use the starter parent, in your pom.xml you need (inside the <build/> element):


and (inside <plugins/>):


Automatic property expansion using Gradle

You can automatically expand info properties from the Gradle project by configuring the Java plugin’s processResources task to do so:

processResources {

You can then refer to your Gradle project’s properties via placeholders, e.g.


40.4.2 Git commit information

Another useful feature of the info endpoint is its ability to publish information about the state of your git source code repository when the project was built. If a git.properties file is contained in your jar the git.branch and git.commit properties will be loaded.

For Maven users the spring-boot-starter-parent POM includes a pre-configured plugin to generate a git.properties file. Simply add the following declaration to your POM:


A similar gradle-git plugin is also available for Gradle users, although a little more work is required to generate the properties file.