Start Learning
Javaneer
Back to stage
Module 1·Spring Boot Essentials

Actuator: Production-Ready Endpoints

Health, info, and metrics endpoints out of the box - and how to expose them safely.

16 min readIntermediate
On this page

A running app in production raises constant questions: Is it healthy? How much memory is it using? What's its request rate? What version is deployed? Spring Boot Actuator answers all of these out of the box, exposing operational endpoints without you writing any monitoring code.

Add it

<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>

That single starter adds a set of /actuator/* HTTP endpoints.

The endpoints you'll use most

EndpointTells you
/actuator/healthIs the app (and its DB, disk, etc.) up? UP or DOWN
/actuator/infoArbitrary app info - build version, git commit
/actuator/metricsMetrics like JVM memory, CPU, HTTP request timings
/actuator/loggersView and change log levels at runtime
curl http://localhost:8080/actuator/health
Output
{"status":"UP","components":{"db":{"status":"UP"},"diskSpace":{"status":"UP"}}}
Actuator is the dashboard of your car

You don't pop the hood every few minutes to check the oil and temperature - the dashboard surfaces the vital signs at a glance, and warning lights fire when something needs attention. Actuator is your app's dashboard: /health is the warning-light system your load balancer watches, and /metrics is the gauges your monitoring tools read.

Health is the one operators wire up

/actuator/health is the most important endpoint because orchestrators use it. A Kubernetes liveness probe restarts a container that stops reporting UP; a readiness probe keeps traffic away until the app is ready. Boot aggregates contributors (database, disk space, custom checks) into one overall status - and you can add your own:

@Component
class CatalogHealthIndicator implements HealthIndicator {
    @Override
    public Health health() {
        return catalogReachable()
            ? Health.up().withDetail("books", 1284).build()
            : Health.down().withDetail("reason", "catalog unreachable").build();
    }
}

Expose endpoints deliberately

By default Boot exposes only /health over HTTP - the rest are hidden, because some (like /loggers or /env) reveal sensitive detail. You opt in explicitly:

management:
  endpoints:
    web:
      exposure:
        include: health, info, metrics    # expose exactly what you want
  endpoint:
    health:
      show-details: when-authorized       # hide component details from anonymous users

Actuator endpoints can leak - secure them

Endpoints like /env, /beans, /heapdump, and /loggers expose configuration and internals. Only expose what you need, and put the actuator endpoints behind authentication (you'll wire this up in the Security module) or on a separate, non-public management port.

Wire a container health check

Your BookVault container is orchestrated by Kubernetes. Which Actuator endpoint should the liveness probe hit, what does the app need to return to be considered alive, and why is exposing that endpoint safe when exposing /actuator/env would not be?

Why does Spring Boot expose only the health endpoint over HTTP by default?

Key takeaways

  • spring-boot-starter-actuator adds production-ready /actuator/* endpoints with no code.
  • Key endpoints: /health (up/down), /info (build/version), /metrics (JVM, HTTP), /loggers (runtime log levels).
  • /actuator/health is what orchestrators watch - Kubernetes liveness/readiness probes rely on it; you can add custom HealthIndicators.
  • By default only health is exposed over HTTP; opt in to others via management.endpoints.web.exposure.include.
  • Actuator endpoints can leak sensitive data - expose the minimum and secure them behind auth or a separate port.
Was this lesson helpful?
Edit this page on GitHub