LearnAI ToolsCareerPractice BuildsPlayContact
Lesson 2619 min read

Spring Boot Actuator

Add the Actuator starter to a Spring Boot application, inspect the /actuator/health endpoint, and expose metrics endpoints for monitoring.

Introduction

Once an application is deployed, someone needs a way to answer basic operational questions without reading source code: is it up, is it healthy, how much memory is it using? Spring Boot Actuator answers exactly those questions by exposing production-ready endpoints for monitoring and management. In this lesson you will add the Actuator starter, inspect /actuator/health, and expose additional endpoints including metrics.

What You Will Learn
  • What Actuator provides out of the box.
  • How to add spring-boot-starter-actuator.
  • How to read and customize the /actuator/health endpoint.
  • How to expose additional endpoints such as /actuator/metrics.
  • Why Actuator endpoints need to be secured.

What Is Actuator?

Actuator is a Spring Boot starter that adds a set of HTTP endpoints (and optionally JMX beans) exposing information about the running application - health status, environment properties, configured beans, HTTP request metrics, thread dumps, and more. It is the standard way production Spring Boot applications integrate with monitoring tools, load balancer health checks, and container orchestration platforms like Kubernetes.

EndpointWhat It Shows
/actuator/healthOverall application health, and health of dependencies like the database
/actuator/infoArbitrary application info you configure, such as build version
/actuator/metricsIndividual metrics like memory usage, HTTP request counts, and JVM stats
/actuator/envResolved configuration properties from all property sources
/actuator/beansEvery bean currently registered in the application context

Adding the Actuator Starter

Add spring-boot-starter-actuator as a dependency. No further configuration is required to get basic endpoints working.

<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
Only /health and /info Are Exposed by Default

Out of the box, only /actuator/health and /actuator/info are exposed over HTTP. Every other endpoint exists internally but must be explicitly exposed, which is a safety measure so sensitive information is not accidentally published.

The Health Endpoint

The health endpoint returns a simple status that load balancers and orchestrators use to decide whether an instance is receiving traffic. By default it returns only a top-level status, but you can show more detail.

curl http://localhost:8080/actuator/health
Response (default)

Click Run to see what this code prints.

# application.properties
management.endpoint.health.show-details=always
Response (with details)

Click Run to see what this code prints.

Actuator automatically detects components on the classpath - such as a DataSource - and contributes a health indicator for each one, so the database check above appears with no extra code once a datasource is configured.

Exposing More Endpoints

Use management.endpoints.web.exposure.include to control which endpoints are reachable over HTTP. A comma-separated list names specific endpoints, or * exposes everything (only recommended behind a secured, internal network).

# application.properties
management.endpoints.web.exposure.include=health,info,metrics,env
curl http://localhost:8080/actuator
Response

Click Run to see what this code prints.

Metrics Endpoint

The metrics endpoint exposes individual measurements. Hitting /actuator/metrics on its own lists every available metric name; appending a specific name returns that metric's value.

curl http://localhost:8080/actuator/metrics/jvm.memory.used
Response

Click Run to see what this code prints.

Micrometer Underneath

Actuator metrics are backed by Micrometer, a vendor-neutral metrics facade. Adding a dependency like micrometer-registry-prometheus lets the same metrics be scraped by Prometheus with no changes to application code.

Securing Actuator Endpoints

Endpoints like /actuator/env and /actuator/beans can reveal configuration details, including things that overlap with secrets if you are not careful. If Spring Security is on the classpath, restrict access so only authorized callers can reach sensitive endpoints.

@Bean
public SecurityFilterChain actuatorSecurity(HttpSecurity http) throws Exception {
http.securityMatcher("/actuator/**")
.authorizeHttpRequests(auth -> auth
.requestMatchers("/actuator/health", "/actuator/info").permitAll()
.anyRequest().hasRole("ADMIN")
)
.httpBasic(Customizer.withDefaults());
return http.build();
}

Common Mistakes

Avoid These Mistakes
  • Setting management.endpoints.web.exposure.include=* on a public, unsecured internet-facing service.
  • Assuming /actuator/health alone tells you everything is fine, without checking component-level detail.
  • Forgetting that sensitive property values in /actuator/env should be masked, not just hidden by omission.
  • Not restricting Actuator endpoints with a dedicated security rule separate from the main API.
  • Ignoring metrics entirely until an incident, instead of wiring them into a dashboard proactively.

Best Practices

  • Expose only the endpoints you actually need, not the full wildcard, in production.
  • Put Actuator endpoints behind authentication, ideally on a separate management port.
  • Use management.endpoint.health.show-details=when-authorized rather than always in public deployments.
  • Wire /actuator/health into your load balancer or orchestrator's health check configuration.
  • Export metrics to a real monitoring system (Prometheus, Datadog, etc.) instead of only checking them manually.

Frequently Asked Questions

Yes. Setting management.server.port to a different value serves all Actuator endpoints on that port, which makes it easy to keep management endpoints off the public-facing port entirely.

The overhead is minimal. Health checks and metric collection are lightweight, and endpoints are only computed when actually requested, not continuously in the background.

No - the health and metrics endpoints are also useful during local development and in CI, for example to wait until a container is ready before running integration tests against it.

Key Takeaways

  • spring-boot-starter-actuator adds production-ready monitoring endpoints with almost no configuration.
  • Only /actuator/health and /actuator/info are exposed by default; others must be opted in.
  • management.endpoint.health.show-details reveals per-component health information.
  • /actuator/metrics exposes individual measurements backed by Micrometer.
  • Actuator endpoints should be secured, since some reveal internal configuration details.

Summary

Actuator turns operational questions - is it up, is it healthy, how is it performing - into simple HTTP endpoints your monitoring tools can consume automatically. Add the starter, expose only what you need, and secure anything sensitive before shipping to production.

Next Lesson →

Securing APIs with Spring Security Basics