Client Applications

Show Version in Application List

For Spring Boot applications the easiest way to show the version, is to use the build-info goal from the spring-boot-maven-plugin, which generates the META-INF/ See also the Spring Boot Reference Guide.

For non-Spring Boot applications you can either add a version or build.version to the registration metadata and the version will show up in the application list.


To generate the build-info in a gradle project, add the following snippet to your build.gradle:

springBoot {

JMX-Bean Management

ATTENTION: Spring Boot 3 does currently not support Jolokia, so this will not work with Spring Boot 3 based applications. You can still monitor Spring Boot 2 applications with Jolokia endpoint using a Spring Boot Admin 3 server.

To interact with JMX-beans in the admin UI you have to include Jolokia in your application. As Jolokia is servlet based there is no support for reactive applications. In case you are using the spring-boot-admin-starter-client it will be pulled in for you, if not add Jolokia to your dependencies. With Spring Boot 2.2.0 you might want to set spring.jmx.enabled=true if you want to expose Spring beans via JMX.


Logfile Viewer

By default the logfile is not accessible via actuator endpoints and therefore not visible in Spring Boot Admin. In order to enable the logfile actuator endpoint you need to configure Spring Boot to write a logfile, either by setting logging.file.path or

Spring Boot Admin will detect everything that looks like an URL and render it as hyperlink.

ANSI color-escapes are also supported. You need to set a custom file log pattern as Spring Boot’s default one doesn’t use colors.

To enforce the use of ANSI-colored output, set spring.output.ansi.enabled=ALWAYS. Otherwise Spring tries to detect if ANSI-colored output is available and might disable it. (1)
logging.pattern.file=%clr(%d{yyyy-MM-dd HH:mm:ss.SSS}){faint} %clr(%5p) %clr(${PID}){magenta} %clr(---){faint} %clr([%15.15t]){faint} %clr(%-40.40logger{39}){cyan} %clr(:){faint} %m%n%wEx (2)
1 Destination the logfile is written to. Enables the logfile actuator endpoint.
2 File log pattern using ANSI colors.

Show Tags per Instance

Tags are a way to add visual markers per instance, they will appear in the application list as well as in the instance view. By default no tags are added to instances, and it’s up to the client to specify the desired tags by adding the information to the metadata or info endpoint.
#using the metadata

#using the info endpoint

Spring Boot Admin Client

The Spring Boot Admin Client registers the application at the admin server. This is done by periodically doing a HTTP post request to the SBA Server providing information about the application.

There are plenty of properties to influence the way how the SBA Client registers your application. In case that doesn’t fit your needs, you can provide your own ApplicationFactory implementation.
Table 1. Spring Boot Admin Client configuration options
Property name Description Default value


Enables the Spring Boot Admin Client.



Comma separated ordered list of URLs of the Spring Boot Admin server to register at. This triggers the AutoConfiguration. Mandatory.


Http-path of registration endpoint at your admin server.



Username and password in case the SBA Server api is protected with HTTP Basic authentication.


Interval for repeating the registration (in ms).



Connect timeout for the registration (in ms).


Read timeout for the registration (in ms).


If set to true the periodic task to register the application is automatically scheduled after the application is ready.


Switch to enable auto-deregistration at Spring Boot Admin server when context is closed. If the value is unset the feature is active if a running CloudPlatform was detected.



If set to true the client will only register against one admin server (in order defined by spring.boot.admin.instance.url); if that admin server goes down, will automatically register against the next admin server. If false, will register against all admin servers.


Health-url to register with. Can be overridden in case the reachable URL is different (e.g. Docker). Must be unique in registry.

Guessed based on management-url and

Base url for computing the management-url to register with. The path is inferred at runtime, and appended to the base url.

Guessed based on management.port, service-url and server.servlet-path.

Management-url to register with. Can be overridden in case the reachable url is different (e.g. Docker).

Guessed based on management-base-url and management.context-path.


Base url for computing the service-url to register with. The path is inferred at runtime, and appended to the base url. In Cloudfoundry environments you can switching to https like this: spring.boot.admin.client.instance.service-base-url=https://${vcap.application.uris[0]}

Guessed based on hostname, server.port.


Service-url to register with. Can be overridden in case the reachable url is different (e.g. Docker).

Guessed based on service-base-url and server.context-path.


Service-path to register with. Can be overridden in case the reachable path is different (e.g. context-path set programmatically).


Name to register with.

${} if set, "spring-boot-application" otherwise.


Select which information should be considered when sending the host of a service:
* IP: Uses the IP returned by InetAddress.getHostAddress()
* HOST_NAME: Uses the host name of a single machine returned by InetAddress.getHostName()
* CANONICAL_HOST_NAME: Uses the FQDN returned by InetAddress.geCanonicalHostName()
If server.address or management.address is set in the service, the value will overrule this property.



Metadata key-value-pairs to be associated with this instance.


Tags as key-value-pairs to be associated with this instance.

Table 2. Instance metadata options
Key Value Default value

Credentials being used to access the endpoints.