Explain Spring Boot Actuator.

Why interviewers love this: Actuator is the part of Spring Boot that tells you whether your app is healthy, visible, and measurable once it is running in production.

Question: Explain Spring Boot Actuator.

Answer: Spring Boot Actuator adds production-ready features to a Spring Boot app, such as health checks, metrics, environment details, and application info. It exposes these through built-in endpoints like /actuator/health and /actuator/metrics, so ops teams and monitoring tools can see what the app is doing without logging into the server.

Interview-Ready Answer: I use Spring Boot Actuator to make a Spring Boot app production-ready. It gives me built-in endpoints for health, metrics, info, environment details, and more, so I can monitor the app and wire it into tools like Kubernetes, Prometheus, or a load balancer. I like that it is very configurable: I can expose only safe endpoints, secure them, and even add custom health checks for things like a database or cache.

What Spring Boot Actuator is

Spring Boot Actuator is a set of production-focused features that sit beside your business code. Think of observability as the ability to understand a running system from its outputs; Actuator gives you those outputs in a standard way. It is especially useful in production because you need answers to questions like: Is the app alive? Can it receive traffic? Is the database slow? How many requests per second are we handling?

How it works under the hood

1. You add the dependency. Once spring-boot-starter-actuator is on the classpath, Spring Boot auto-configures a set of endpoint beans. An endpoint is a managed component that can expose a small piece of runtime information.
2. Boot creates an endpoint registry. Spring scans for built-in endpoints such as health, info, metrics, env, and beans. Some are safe to expose; others are sensitive and stay hidden unless you opt in.
3. Exposure rules decide what is reachable. The property management.endpoints.web.exposure.include controls which endpoints are reachable over HTTP. The base path is usually /actuator. You can also move management traffic to another port with management.server.port.
4. The web layer maps endpoint IDs to URLs. For example, the health endpoint becomes /actuator/health. Spring adds a handler mapping so these endpoints behave like normal web routes, but they are not your business controllers.
5. Health is aggregated. A HealthIndicator is a small check that returns UP, DOWN, or OUT_OF_SERVICE. Actuator combines all indicators into one health response, so a database, cache, and disk check can all contribute to the final answer.
6. Metrics are collected through Micrometer. Micrometer is Spring Boot’s metrics library. Counters, timers, and gauges are recorded in the app and then exported to tools like Prometheus, Datadog, or New Relic.
7. Security still matters. Actuator does not magically make endpoints safe. In real systems, you protect them with Spring Security, network rules, or a separate management port, and you expose only what you need.

What you typically use it for

• Health checks: Let Kubernetes or a load balancer know whether the app should receive traffic.
• Metrics: Track request counts, latency, JVM memory, garbage collection, and thread usage.
• Operational info: Show build version, git commit, or custom deployment details.
• Diagnostics: Inspect environment values, beans, mappings, and log levels during incident response.

Health, readiness, and liveness

These terms are often confused, so keep them separate. Health is the overall status. Readiness means the instance can receive traffic. Liveness means the instance is not stuck and should not be restarted. Since Spring Boot 2.3, Boot supports health groups such as readiness and liveness, which is very useful in Kubernetes.

When and why to use it

1. Use it in every production app. It saves time during deployment, incident response, and capacity planning.
2. Use health indicators for dependencies. Check things like a database connection pool or cache availability, but keep the check fast and local. A good target is usually well under 100 ms.
3. Use metrics for trends. Metrics are better than logs for answering, ‘What changed over the last hour?’ because they are numeric and easy to graph.
4. Use a separate management port when needed. If your app is public-facing, putting Actuator on 8081 while the app stays on 8080 reduces accidental exposure.

Performance and edge cases

Most Actuator endpoints are lightweight. A health request is roughly O(k), where k is the number of health indicators being evaluated, because it must ask each indicator for its status. Metrics collection is usually near O(1) at the point where the event is recorded, because timers and counters are updated incrementally. The expensive part is not the endpoint framework; it is the work your custom checks do. If you call a slow external service inside a health check, you can make the endpoint slow, trigger probe failures, or even cause restart loops.

One more important detail: exposing /actuator/env, /actuator/beans, or /actuator/configprops publicly can leak secrets or internal structure, so do not use * casually in production. Keep the default safe, then opt in only to endpoints you really need.

Real-world production story

Imagine a checkout service for an e-commerce site running in Kubernetes. The team exposes /actuator/health/readiness so the cluster only sends traffic to pods that can actually charge cards. They also expose /actuator/metrics to a Prometheus dashboard so they can watch request latency, payment failure rate, and JVM memory during flash sales.

Here is the incident that Actuator helps prevent. A developer once added a slow payment-gateway ping to the liveness check instead of the readiness check. When the gateway had a brief outage, Kubernetes thought the app was broken and restarted the pods over and over. The logs filled with lines like Liveness probe failed, the pods never stayed up long enough to recover, and customers saw 502 errors at checkout. The fix was to move dependency checks to readiness and keep liveness focused on ‘is the process stuck or dead?’ That one change stopped the restart loop and let the service recover gracefully.

In the real world, Actuator is the difference between guessing and knowing. It turns a mystery outage into a measurable signal.

Follow-up & Tricky Questions:

• How do you expose only selected Actuator endpoints? Use management.endpoints.web.exposure.include to list only what you need, such as health, info, and metrics. Avoid * unless you are in a locked-down internal environment.
• What is the difference between management.endpoint.<id>.enabled and exposure? Enabling controls whether the endpoint bean exists at all; exposure controls whether that enabled endpoint is reachable over HTTP or JMX. You can disable an endpoint completely, or keep it enabled but not exposed.
• How do you secure Actuator endpoints? Put them behind Spring Security, restrict access by role, and often isolate them on a private network or a separate management port. Security is not optional because endpoints like env and beans can reveal sensitive operational details.
• Can Actuator run on a different port from the app? Yes. Set management.server.port to move management traffic to a separate port, which helps isolate admin endpoints from public traffic.
• How do custom health checks work? Implement HealthIndicator for blocking code or ReactiveHealthIndicator for reactive stacks. Spring Boot collects those checks and merges them into the final health response.
• Is Actuator only for web apps? No. It can also expose endpoints through JMX, which is a JVM management mechanism. Web exposure is just the most common choice in cloud deployments.
• Does /actuator/health always mean the app is ready for traffic? No. Health is an aggregate status; readiness is the specific signal for traffic routing. A service can be alive but not ready if a dependency is still starting up.
• Is show-details=always enough to make health safe? No. That setting only changes how much detail is returned; it does not protect the endpoint. You still need authentication, authorization, and careful exposure rules.
• Should I put database pings in liveness? Usually no. Liveness should answer whether the process is stuck or dead, while dependency checks belong in readiness so the platform can stop sending traffic without restarting the app in a loop.

Tricky / gotcha questions:

• Do Actuator endpoints replace your application controllers? No. They are separate management endpoints for operational data; your business APIs still live in normal @RestController classes.
• Are all Actuator endpoints exposed by default? No. Spring Boot keeps the default surface area small, and you must explicitly expose most endpoints you want to reach over HTTP.
• Is the health endpoint expensive? Usually not, but it can become expensive if you make each health indicator call a slow external system. The framework is lightweight; the custom check is what can hurt you.

Common Mistakes:

• Exposing everything with *. Correction: expose only the endpoints you need, because env, beans, and similar endpoints can leak sensitive information.
• Putting slow remote calls in health checks. Correction: keep health checks fast and local when possible; use readiness for dependency awareness, not deep dependency chains.
• Using liveness for dependency failures. Correction: liveness should detect a stuck process, while readiness should detect whether the instance can safely take traffic.
• Forgetting security and network isolation. Correction: protect Actuator with Spring Security, private networking, or a separate management port.

Memory Hook: Think of Actuator as your app’s dashboard: health is the warning light, readiness is the ‘ready to drive’ sign, and metrics are the speedometer and fuel gauge. If you remember one line, remember this: Actuator tells you whether the app is alive, ready, and behaving.

Cheat Sheet:

• Actuator adds production-ready endpoints to Spring Boot.
• Common endpoints: health, info, metrics, env, beans.
• Default web exposure is small; opt in to more endpoints.
• Use readiness for traffic, liveness for restart decisions.
• Secure Actuator like any admin interface.
• Custom checks come from HealthIndicator and custom data from InfoContributor.

Practice Tasks:

• Add the Actuator dependency to a sample app and open /actuator/health.
• Create a custom HealthIndicator for a fake cache and make it return DOWN with a system property.
• Set up management.server.port=8081 and expose only health and info.