Actuator, health checks and useful logging

A production application needs to be observable — you must be able to see that it is healthy, what it is doing, and what went wrong. Spring Boot Actuator provides health checks, metrics and info endpoints out of the box, and Spring Boot's logging gives you the record of what happened. This lesson is how to make a Dakiya deployment observable, verified against the running app.

Actuator: health, metrics and info for free

Add spring-boot-starter-actuator and Spring Boot exposes operational endpoints under /actuator. You choose which to expose:

management.endpoints.web.exposure.include=health,info,metrics

The endpoints you will use most:

• /actuator/health — is the app healthy? Verified against the running app: GET /actuator/health returned {"status":"UP"} with HTTP 200. It aggregates component health checks (database, disk, etc.), so "UP" means the app and its dependencies are reachable.
• /actuator/metrics — runtime metrics (memory, threads, HTTP request timings, database pool usage) you can query or scrape.
• /actuator/info — arbitrary app info (build version, git commit) you configure.

/actuator/health is the one that matters most operationally: it is what a load balancer, Kubernetes, or a platform's health check calls to decide whether an instance is alive and should receive traffic. A verified {"status":"UP"} is exactly what those systems look for.

Health checks and readiness

Actuator's health endpoint drives real infrastructure decisions, so understand its two roles:

• Liveness — is the app running at all? If not, the platform restarts it.
• Readiness — is the app ready to serve traffic (started up, database connected)? If not, the platform holds traffic off it until it is.

Spring Boot supports liveness and readiness probes (/actuator/health/liveness and /actuator/health/readiness) designed for exactly this — Kubernetes and similar platforms poll them. Configure your platform's health check to hit /actuator/health (or the specific probe), so a sick instance is automatically restarted or taken out of rotation. This is the difference between an outage that self-heals and one that needs a human. Wire the platform's health check to Actuator.

Secure the Actuator endpoints

A caution: Actuator endpoints can expose sensitive operational data (configuration, environment, metrics), so in production you secure them. Expose only what you need (health and perhaps info publicly; metrics and anything sensitive behind authentication), and never expose the more dangerous endpoints (env, heapdump, loggers with write access) unauthenticated. The default in recent Spring Boot is conservative (only health exposed over the web), which is the right starting point — open up further deliberately, and put a security rule on the sensitive endpoints. Do not expose /actuator/** wide open in production.

Logging for production

Spring Boot logs via SLF4J/Logback (the exceptions-and-logging lesson). For production, a few deployment concerns beyond writing good log statements:

• Levels. Set production to INFO (or WARN) at the root, raising specific packages to DEBUG only when investigating. DEBUG everywhere floods the logs and hurts performance.
• Structured logging. For production, log in a machine-parseable format (JSON) so a log system (ELK, CloudWatch, Loki) can index and search it. Spring Boot 3.4+ supports structured logging via a property; otherwise a Logback encoder does it.
• Log to stdout, let the platform collect. In containers and modern platforms, the convention is to log to standard out and let the platform capture and ship the logs — do not write to local files the container will lose. This is the twelve-factor "logs as event streams" approach.
• Correlation. For tracing a request across logs (and services), include a request/trace id (Spring Boot's Micrometer Tracing adds trace ids automatically) so you can follow one request's log lines.

The goal: when something happens in production, you can find out — the health endpoint tells you the app is up, metrics tell you how it is behaving, and searchable logs (with trace ids) tell you what a specific request did. Set this up before deploying; observability configured after an incident is too late.

Check your work

Actuator. spring-boot-starter-actuator exposes operational endpoints under /actuator (choose with management.endpoints.web.exposure.include): health (verified {"status":"UP"}, 200 — aggregates component checks), metrics (runtime metrics), info.

Health checks. /actuator/health (and liveness/readiness probes) drive platform decisions — restart a dead instance (liveness), hold traffic off a not-ready one (readiness). Wire the platform's health check to it.

Secure it. Actuator can expose sensitive data — expose only what you need (health/info public, metrics/sensitive behind auth), never env/heapdump unauthenticated; the conservative default is the right start.

Logging for production. INFO/WARN levels (DEBUG only when investigating); structured (JSON) logs for a log system; log to stdout for the platform to collect (not local files); trace/correlation ids to follow a request. Set up before deploying.

Practice

1. Add Actuator, expose health, and confirm /actuator/health returns {"status":"UP"} with 200 (reproduce the verified result).
2. Expose metrics and query /actuator/metrics/jvm.memory.used; observe the runtime data.
3. Reason about what a load balancer or Kubernetes does with /actuator/health (readiness/liveness) and configure a probe endpoint.
4. Put a security rule so metrics requires authentication while health stays public; confirm the difference.
5. Set production log level to INFO, raise one package to DEBUG, and confirm only that package is verbose.
6. Configure logging to stdout in JSON and reason about why local log files are wrong in a container.

Official documentation

• Spring Boot — Actuator — Endpoints, health, metrics, exposure.
• Spring Boot — Health information and probes — Liveness/readiness for platforms.
• Spring Boot — Logging (structured, levels) — Production logging.

Next: containerising a Spring Boot application.