Recommended Free Tools
Spring Boot Actuator adds operational endpoints for monitoring and managing a Spring Boot application over HTTP or JMX. Add the Actuator starter, then choose which endpoints to expose, who can reach them, and where metrics should be sent. Health is exposed by default; most other endpoints require deliberate configuration.
What Spring Boot Actuator does
Actuator is Spring Boot’s production-oriented set of monitoring and management features. Its built-in endpoints can report health, metrics, configuration, and other diagnostic information. It supplies useful operational interfaces, but does not by itself create dashboards, alerts, deployment safeguards, or a complete observability setup. Those require additional configuration and, for ongoing monitoring, an appropriate monitoring system.
The usual dependency is org.springframework.boot:spring-boot-starter-actuator. Add it using the dependency-management approach already used by your Maven or Gradle project. The exact endpoints and configuration properties should be checked against the documentation for the Spring Boot version your application actually runs; the current reference describes Spring Boot 4.1.1 as stable and 4.2.0-M2 as a development release. Spring Boot Actuator overview
How Actuator endpoints become available
An endpoint is usable only when it exists for the application, access is allowed, and it is exposed through the chosen technology. For web endpoints, the default path pattern is /actuator/{id}, making the health URL /actuator/health. Health is the default exposed endpoint over both HTTP and JMX; other endpoints are not automatically exposed.
#1 Best Overall
Choose exposure deliberately
Use management.endpoints.web.exposure.include to select HTTP endpoints and management.endpoints.jmx.exposure.include for JMX. The corresponding exclude properties remove endpoints, and exclusions take precedence over inclusions. Wildcards are available, but exposing everything can reveal operational details or permit changes you did not intend. Review each endpoint and its data before enabling it.
The reference lists endpoints including auditevents, beans, caches, conditions, configprops, env, flyway, health, httpexchanges, info, integrationgraph, loggers, liquibase, metrics, mappings, quartz, scheduledtasks, and sessions. Availability can depend on a bean or supporting library. These are not a checklist of safe defaults: for example, loggers can change logger configuration, while sessions can retrieve or delete sessions. Spring Boot endpoint reference
Secure the access path
Endpoint exposure and authorization are separate decisions: an endpoint must be exposed, and the application must still control who can access it. Diagnostic endpoints such as env, configprops, beans, loggers, mappings, and sessions can disclose or alter useful operational information. Do not make them broadly reachable without reviewing the contents and enforcing suitable access controls.
Spring Boot’s actuator security auto-configuration backs off when the application defines its own Spring Security SecurityFilterChain. In that case, the application’s security configuration must establish the relevant access rules. Check the complete security setup rather than assuming that Actuator defaults still apply.
Customize the management URL and listener
Set management.endpoints.web.base-path to change the web endpoint prefix. For example, setting it to /manage changes the health URL from /actuator/health to /manage/health. Individual endpoint paths can also be remapped.
By default, management endpoints use the application’s web server. The management.server.port property can assign them a separate port; the management server address can also be restricted, for example to localhost when using a different port. To disable management endpoints over HTTP, set management.server.port=-1 or exclude all web endpoints. A separate port is not a security boundary on its own: authentication, deployment routing, and firewall policy still determine who can reach it. Spring Boot monitoring and management over HTTP
Use health checks for status and diagnosis
A GET /actuator/health request returns an aggregate application health status. To inspect a particular contributor, request a component path such as /actuator/health/{component}; nested components can be addressed with further path segments. Responses can include a status and details, but the available indicators and component contents depend on the application’s dependencies and health contributors. Health endpoint API
Control component and detail visibility
Configure management.endpoint.health.show-details and management.endpoint.health.show-components to control how much health information appears. Documented options include never, when-authorized, and always; the documented default for details is never. Full details may reveal infrastructure information such as database names or versions, so choose visibility according to who can access the endpoint.
Do not assume that a generic aggregate health response is equivalent to a deployment’s liveness or readiness policy. Use the probe guidance for the application’s Spring Boot version when configuring orchestration checks. Health endpoint configuration reference
Rank #4
Collect and export metrics with Micrometer
Actuator integrates with Micrometer, including dependency management and auto-configuration. Spring Boot configures a composite MeterRegistry and adds registries for supported implementations on the classpath. The reference names integrations including Prometheus, OTLP, Datadog, New Relic, Graphite, Influx, and JMX; select and configure a backend appropriate to the deployment. Spring Boot metrics reference
What meters may be available
Automatically registered meter families can include:
- JVM memory, garbage collection, threads, loaded classes, and JIT time.
- System, process, and disk information such as CPU, file descriptors, uptime, and disk availability.
- Application startup measurements named
application.started.timeandapplication.ready.time.
Exact meter availability depends on the classpath and runtime. For example, the documentation identifies an additional Micrometer module for virtual-thread statistics.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Use the metrics endpoint for diagnosis
/actuator/metrics lets you inspect meters recorded by the application, but it is not exposed by default. Query names in Micrometer form, such as jvm.memory.max, even if a backend exports a normalized name such as jvm_memory_max. Tags can be used to filter a meter’s results. Use a configured monitoring backend for persistent dashboards and alerts rather than treating this diagnostic endpoint as a metrics store.
Choose an Actuator design that fits the application
There is no universally correct endpoint topology for every application. Decide based on the operational purpose and deployment:
Quick Recap
- Check purpose: use aggregate health for broad status checks; use component paths when targeted diagnosis is needed.
- Transport and reachability: decide between HTTP and JMX, a shared or separate management listener, and the networks allowed to reach it.
- Access policy: define which endpoints are exposed, authenticated, role-restricted, or excluded, accounting for any custom Spring Security filter chain.
- Metrics destination: choose the Micrometer registry and backend, then confirm how meter names and tags map to the monitoring system.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
