Spring Boot Management Endpoints Configuration Guide

Understand Actuator exposure, health checks, security boundaries, and troubleshooting steps.

Written and maintained by ErickPang ยท Updated

Understand Actuator management endpoint exposure, health checks, security boundaries, and YAML/Properties configuration.

What management endpoints are

Spring Boot Actuator provides endpoints for health checks, metrics, environment information, and runtime status. Developers and operators often rely on health, info, and metrics to confirm service behavior.

These endpoints are useful, but they also carry security risk. Do not expose env, beans, configprops, or similar endpoints freely in production because they may reveal sensitive information. Separate local debugging, testing, and production settings.

Common exposure configuration

Spring Boot exposes only health over HTTP by default. Production should keep that least-exposure posture and add only endpoints that are actually needed, such as controlled info output. Restrict everything else to private networks or authenticated access after deciding who needs it and whether a gateway enforces the boundary.

If an endpoint cannot be reached, first confirm spring-boot-starter-actuator is included, then check exposure.include, management.server.port, and application context path.

management:
  endpoints:
    web:
      exposure:
        include: "health,info"
  endpoint:
    health:
      show-details: when_authorized

Troubleshooting checklist

When endpoint configuration does not work, do not inspect YAML alone. Confirm dependencies, profiles, ports, and security settings. Some projects separate the management port from the application port or hide paths behind a gateway.

For production, treat Actuator settings as a release checklist item, especially endpoint exposure and health detail level.

  • Confirm spring-boot-starter-actuator is included
  • Confirm exposure.include contains the target endpoint
  • Confirm management port and context path
  • Confirm security settings do not block or overexpose endpoints

include, exclude, and wildcards

exposure.include selects the remotely available endpoint IDs, while exposure.exclude removes IDs and takes precedence. An asterisk has special meaning in YAML, so a wildcard used for local diagnostics must be quoted as "*".

Do not copy include: "*" into production. env, configprops, beans, loggers, and other endpoints can reveal configuration structure or change runtime state. Even with Spring Security, review access rules endpoint by endpoint instead of treating 'requires login' as permission to expose everything.

management:
  endpoints:
    web:
      exposure:
        include: "*"
        exclude: "env,beans,configprops"

Verify paths, status codes, and security boundaries

The default health URL is /actuator/health. management.endpoints.web.base-path, server.servlet.context-path, or a separate management.server.port changes the final URL. A separate port changes where the endpoint listens; it does not automatically add authentication or network isolation.

Check health and one unexposed endpoint locally. Health should return its JSON response, while an endpoint outside the exposure set should normally return 404. With Spring Security, test anonymous and authorized requests separately so protected endpoints return 401, 403, or are not routed publicly at all.

curl -i http://localhost:8080/actuator/health
curl -i http://localhost:8080/actuator/env

# expected: health is available; env is not exposed

Primary references and related guides

Spring Boot's Actuator reference separates endpoint enabled state, exposure, and access. Troubleshooting must check all three layers rather than only confirming that an endpoint bean exists.

Related guides

Independently maintained by ErickPang. Not affiliated with Spring, JetBrains, or Broadcom.