Using Spring Boot Actuator for application monitoring and health checks

A production application needs more than a successful deployment. Teams must know whether a service is responding, whether its database connection is usable, and whether the application can safely receive traffic. Spring Boot Actuator adds these operational features with sensible defaults and a consistent HTTP interface.

For Australian development teams, this is particularly useful when systems serve customers across Sydney, Melbourne, Brisbane and Perth. Clear health signals help engineers distinguish an application failure from a database outage, network delay or a regional cloud issue without exposing private customer information.

What Spring Boot Actuator provides

Spring Boot Actuator is enabled by adding the Actuator starter to a Maven or Gradle project. It supplies endpoints for application health, metrics, environment details, loggers, scheduled tasks and build information. The exact endpoint set depends on the Spring Boot version and which integrations are present.

The /actuator/health endpoint is the usual starting point. It can report the status of the application itself and connected components such as a relational database, Redis, messaging broker or external service. A simple UP response is useful, but component-level details are more valuable during incident diagnosis.

Enabling useful monitoring endpoints

By default, Spring Boot exposes only a limited set of endpoints over HTTP. A common configuration is management.endpoints.web.exposure.include=health,info,metrics,prometheus, with the values kept deliberately small. Exposing every endpoint can reveal configuration and operational data that should remain private.

The metrics endpoint presents measurements such as JVM memory, garbage collection, HTTP request counts and response timing. When Prometheus is used, the Prometheus registry can provide a scrape endpoint for dashboards in Grafana. For teams maintaining Java services or seeking practical Java guidance, this combination creates a useful bridge between application code and an organisation’s wider observability platform.

Designing meaningful health checks

A health check should answer a clear operational question. Liveness indicates whether the process is functioning and should remain running, while readiness indicates whether it is prepared to handle requests. In Kubernetes, enabling management.endpoint.health.probes.enabled=true allows Spring Boot to expose separate liveness and readiness groups.

Readiness checks should include dependencies that are essential for serving traffic, such as the primary database. Liveness should be narrower: a temporary database outage should not necessarily cause Kubernetes to restart every application instance. For a payment or booking platform used during busy Sydney commuting hours, this distinction can prevent a dependency outage from becoming a restart storm.

Protecting actuator endpoints

Actuator endpoints can contain sensitive information, particularly env, configprops, heap dumps and thread dumps. They should not be exposed publicly without authentication, network restrictions and careful authorisation. A common pattern is to expose health checks through an internal load balancer while restricting diagnostic endpoints to an operations network.

Spring Security can require an operations role for metrics and application information while permitting a narrowly scoped health endpoint. Even health responses may need sanitising: database names, cloud metadata and dependency details should not be disclosed to anonymous users. This matters under the Australian Privacy Act and Australian Privacy Principles, which encourage organisations to protect personal and security-related information.

Connecting health checks to infrastructure

A monitoring endpoint becomes valuable when infrastructure acts on its result. A cloud load balancer can stop routing requests to an instance that fails readiness checks, while Kubernetes can remove an unhealthy pod from service. Alerting should use sustained failure, latency thresholds and error rates rather than reacting to one short-lived timeout.

Geography also affects interpretation. A service hosted near Melbourne may show different latency for users in Perth, and an outage affecting an Australian availability zone may appear as a regional problem rather than a complete application failure. Dashboards should therefore separate application errors, dependency health, request duration and traffic by region where that information is available.

Building an operational monitoring routine

Health checks work best alongside logs, traces and business metrics. A healthy process can still reject payments, return incorrect data or experience slow queries. Track indicators such as successful checkout rates, authentication failures, database pool saturation and queue depth, while avoiding passwords, access tokens and unnecessary personal data in logs.

Operational routines should also fit local business cycles. Australian teams often see traffic changes around the end of the financial year, public holidays and major retail campaigns. Review Actuator dashboards before these periods, confirm alert ownership across time zones, and test that recovery procedures work when staff are away rather than assuming a green health page means the whole service is reliable.