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.
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: trueNever 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
1. Which actuator endpoint is exposed over HTTP by default in a fresh Spring Boot application?
2. What is the difference between a liveness probe and a readiness probe?
3. Why should /actuator/env generally not be exposed to the public internet?
4. How can a custom health check for a downstream dependency be added to Actuator?
5. What is a common security practice for isolating actuator endpoints in production?
Was this page helpful?
You May Also Like
Application Properties and Profiles
How Spring Boot externalizes configuration through application.properties/yml, property precedence, and environment-specific profiles.
Logging in Spring Boot
How Spring Boot's default Logback-based logging works, including log levels, per-package configuration, and structured logging for production.
Spring Security Basics
An introduction to how Spring Security protects a Spring Boot application using the servlet filter chain, HTTP security rules, and password encoding.
Related Reading
Related Study Notes in Web Development
Browse all study notesWebSockets Study Notes
Web Development · 30 topics
Web DevelopmentWebAssembly Study Notes
WebAssembly · 30 topics
Web DevelopmentgRPC Study Notes
Protocol Buffers · 30 topics
Web DevelopmentFlask Study Notes
Python · 30 topics
Web DevelopmentDjango Study Notes
Python · 30 topics
Web DevelopmentNext.js Study Notes
JavaScript · 30 topics