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.

endpoints.beans.id=springbeans
endpoints.beans.sensitive=false
endpoints.shutdown.enabled=true

	Note
	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:

endpoints.enabled=false
endpoints.info.enabled=true

Likewise, you can also choose to globally set the “sensitive” flag of all endpoints. By default, the sensitive flag depends on the type of endpoint (see the table above). For example, to mark all endpoints as sensitive except info:

endpoints.sensitive=true
endpoints.info.sensitive=false

If endpoints.hypermedia.enabled is set to true and Spring HATEOAS is on the classpath (e.g. through the spring-boot-starter-hateoas or if you are using Spring Data REST) then the HTTP endpoints from the Actuator are enhanced with hypermedia links, and a “discovery page” is added with links to all the endpoints. The “discovery page” is available on /actuator by default. It is implemented as an endpoint, allowing properties to be used to configure its path (endpoints.actuator.path) and whether or not it is enabled (endpoints.actuator.enabled).

When a custom management context path is configured, the “discovery page” will automatically move from /actuator to the root of the management context. For example, if the management context path is /management then the discovery page will be available from /management.

If the HAL Browser is on the classpath via its webjar (org.webjars:hal-browser), or via the spring-data-rest-hal-browser then an HTML “discovery page”, in the form of the HAL Browser, is also provided.

Cross-origin resource sharing (CORS) is a W3C specification that allows you to specify in a flexible way what kind of cross domain requests are authorized. Actuator’s MVC endpoints can be configured to support such scenarios.

CORS support is disabled by default and is only enabled once the endpoints.cors.allowed-origins property has been set. The configuration below permits GET and POST calls from the example.com domain:

endpoints.cors.allowed-origins=http://example.com
endpoints.cors.allowed-methods=GET,POST

	Tip
	Check EndpointCorsProperties for a complete list of options.

If you add a @Bean of type Endpoint then it will automatically be exposed over JMX and HTTP (if there is an server available). An HTTP endpoints can be customized further by creating a bean of type MvcEndpoint. Your MvcEndpoint is not a @Controller but it can use @RequestMapping (and @Managed*) to expose resources.

Tip

If you are doing this as a library feature consider adding a configuration class annotated with @ManagementContextConfiguration to /META-INF/spring.factories under the key org.springframework.boot.actuate.autoconfigure.ManagementContextConfiguration. If you do that then the endpoint will move to a child context with all the other MVC endpoints if your users ask for a separate management port or address. A configuration declared this way can be a WebConfigurerAdapter if it wants to add static resources (for instance) to the management endpoints.

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 unauthenticated connection in a secure application a simple ‘status’ message is returned, and for an authenticated connection additional details are also displayed (see Section 47.7, “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.

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.

46.6.1 Auto-configured HealthIndicators

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

Name	Description
CassandraHealthIndicator	Checks that a Cassandra database is up.
DiskSpaceHealthIndicator	Checks for low disk space.
DataSourceHealthIndicator	Checks that a connection to DataSource can be obtained.
ElasticsearchHealthIndicator	Checks that an Elasticsearch cluster is up.
JmsHealthIndicator	Checks that a JMS broker is up.
MailHealthIndicator	Checks that a mail server is up.
MongoHealthIndicator	Checks that a Mongo database is up.
RabbitHealthIndicator	Checks that a Rabbit server is up.
RedisHealthIndicator	Checks that a Redis server is up.
SolrHealthIndicator	Checks that a Solr server is up.

	Tip
	It is possible to disable them all using the management.health.defaults.enabled property.

46.6.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.Health;
import org.springframework.boot.actuate.health.HealthIndicator;
import org.springframework.stereotype.Component;

@Component
public class MyHealthIndicator implements HealthIndicator {

    @Override
    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();
    }

}

	Note
	The identifier for a given HealthIndicator is the name of the bean without the HealthIndicator suffix if it exists. In the example above, the health information will be available in an entry named my.

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.

Application information exposes various information collected from all InfoContributor beans defined in your ApplicationContext. Spring Boot includes a number of auto-configured InfoContributors and you can also write your own.

46.7.1 Auto-configured InfoContributors

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

Name	Description
EnvironmentInfoContributor	Expose any key from the Environment under the info key.
GitInfoContributor	Expose git information if a git.properties file is available.
BuildInfoContributor	Expose build information if a META-INF/build-info.properties file is available.

	Tip
	It is possible to disable them all using the management.info.defaults.enabled property.

46.7.2 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.encoding=UTF-8
info.app.java.source=1.8
info.app.java.target=1.8

	Tip
	Rather than hardcoding those values you could also expand info properties at build time. Assuming you are using Maven, you could rewrite the example above as follows: info.app.encoding[email protected]@ info.app.java.source[email protected]@ info.app.java.target[email protected]@

46.7.3 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 GitProperties bean is available, the git.branch, git.commit.id and git.commit.time properties will be exposed.

	Tip
	A GitProperties bean is auto-configured if a git.properties file is available at the root of the classpath. See Generate git information for more details.

If you want to display the full git information (i.e. the full content of git.properties), use the management.info.git.mode property:

management.info.git.mode=full

46.7.4 Build information

The info endpoint can also publish information about your build if a BuildProperties bean is available. This happens if a META-INF/build-info.properties file is available in the classpath.

	Tip
	The Maven and Gradle plugins can both generate that file, see Generate build information for more details.

import java.util.Collections;

import org.springframework.boot.actuate.info.Info;
import org.springframework.boot.actuate.info.InfoContributor;
import org.springframework.stereotype.Component;

@Component
public class ExampleInfoContributor implements InfoContributor {

    @Override
    public void contribute(Info.Builder builder) {
        builder.withDetail("example",
                Collections.singletonMap("key", "value"));
    }

}

{
    "example": {
        "key" : "value"
    }
}