100% Free Forever
AI-Powered Learning
Industry Expert Content
Certificates & Badges
Learn At Your Own Pace
Java

Spring Boot Actuator

How Spring Boot Actuator exposes production-ready monitoring endpoints for health checks, metrics, and application internals.

Security & ConfigIntermediate8 min readJul 10, 2026
Analogies

What Actuator Gives You Out of the Box

Spring Boot Actuator is a starter (spring-boot-starter-actuator) that adds a set of production-ready HTTP endpoints under /actuator for observing a running application's internal state without attaching a debugger or SSHing into a server. Endpoints like /actuator/health report whether the app and its dependencies (database, disk space, message brokers) are up, /actuator/metrics exposes JVM and application-level counters and gauges, /actuator/env shows resolved configuration properties, and /actuator/beans lists every Spring bean in the application context. This turns questions that used to require custom debugging code — 'is the database connection healthy right now?' — into a simple HTTP GET.

🏏

Cricket analogy: It's like a stadium's Hawk-Eye and Snickometer feeds giving broadcasters live diagnostic data — ball speed, trajectory, edge detection — without anyone needing to physically inspect the pitch mid-over.

Health Indicators and Readiness/Liveness

The /actuator/health endpoint aggregates results from multiple HealthIndicator beans — Spring Boot auto-configures ones for the datasource, disk space, and Redis or RabbitMQ connections when those dependencies are present, and you can implement your own by implementing the HealthIndicator interface for a custom downstream dependency. In Kubernetes environments, Actuator's health groups split this into liveness (is the JVM process itself still functioning, should it be restarted?) and readiness (can it currently serve traffic, should it receive requests?) probes, exposed at /actuator/health/liveness and /actuator/health/readiness, which map directly onto Kubernetes' livenessProbe and readinessProbe configuration.

🏏

Cricket analogy: It's like a physio's on-field check distinguishing 'is this player conscious and breathing' (liveness) from 'is this player fit enough to keep batting right now' (readiness) — two different questions with different consequences.

Securing and Exposing Endpoints Selectively

By default, only /actuator/health is exposed over HTTP for security reasons; the rest must be explicitly opted in via management.endpoints.web.exposure.include, and even then, sensitive endpoints like /actuator/env or /actuator/heapdump should be locked behind Spring Security rules and never exposed to the public internet, since they can leak secrets or enable denial-of-service via heap dumps. It's common practice to run the actuator endpoints on a separate management port (management.server.port) that isn't reachable from outside the cluster's internal network, giving you an extra layer of isolation beyond authentication rules alone.

🏏

Cricket analogy: It's like a stadium's public scoreboard (health) being visible to all fans, while the groundstaff's detailed pitch-moisture sensor data (env, heapdump) stays restricted to the curator's office only.

yaml
management:
  server:
    port: 9001   # separate management port, not exposed publicly
  endpoints:
    web:
      exposure:
        include: health, metrics, info
  endpoint:
    health:
      show-details: when-authorized
      probes:
        enabled: true
  health:
    livenessstate:
      enabled: true
    readinessstate:
      enabled: true

Never expose management.endpoints.web.exposure.include: "*" on an internet-facing port. This turns on every actuator endpoint, including /actuator/env (which can leak database passwords and API keys resolved from your configuration) and /actuator/heapdump (which can be used to exhaust memory or extract sensitive in-memory data). Always use an explicit allowlist and restrict sensitive endpoints behind authentication.

  • spring-boot-starter-actuator adds production-ready monitoring endpoints under /actuator.
  • /actuator/health aggregates results from multiple HealthIndicator beans.
  • Liveness probes ask 'is the process alive?'; readiness probes ask 'can it serve traffic now?'.
  • Only /actuator/health is exposed by default; others require explicit opt-in via exposure.include.
  • Sensitive endpoints like /actuator/env and /actuator/heapdump must be secured or hidden.
  • Running actuator on a separate management port adds network-level isolation.
  • Custom HealthIndicator implementations let you monitor application-specific downstream dependencies.

Practice what you learned

Was this page helpful?

Topics covered

#Java#SpringBootStudyNotes#WebDevelopment#SpringBootActuator#Spring#Boot#Actuator#Gives#StudyNotes#SkillVeris