skip to content

How do you disable one built-in health indicator versus all of them, using the management.health.* properties?

level: middleimportance: must knowfreq 55%

answer

  1. management.health.<name>.enabled=false
  2. db not datasource
  3. defaults.enabled=false = opt-in mode
  4. enabled != show-details != exposure
  5. re-enable selectively after defaults off

basics

~10 s

Disable a single indicator with management.health.<name>.enabled=false (e.g. management.health.db.enabled=false, management.health.redis.enabled=false). Disable all built-ins at once with management.health.defaults.enabled=false, then selectively re-enable the ones you want.

solid answer

~40 s

Each auto-configured indicator has an enabled flag keyed by its name: management.health.db.enabled (DataSourceHealthIndicator), management.health.diskspace.enabled, management.health.redis.enabled, management.health.ping.enabled, and so on. Setting one to false removes just that indicator's contribution. To flip the default for everything, set management.health.defaults.enabled=false — this disables all auto-configured indicators unless individually re-enabled, which is the 'opt-in' pattern when you only want a couple of checks. A frequent trap is using the datasource bean name instead of the fixed toggle key: it's management.health.db.enabled, not management.health.datasource.enabled. Note these toggles control whether the indicator runs/contributes, which is different from management.endpoint.health.show-details (whether the body reveals component detail) and from exposing the endpoint at all.

code

java · 12 lines
java
// Disable just the Redis check (e.g. Redis is a non-critical cache)
// application.properties
management.health.redis.enabled=false

// -- OR -- opt-in mode: turn everything off, keep only db + ping
management.health.defaults.enabled=false
management.health.db.enabled=true
management.health.ping.enabled=true

// Note: the DataSource toggle key is 'db', NOT 'datasource':
//   management.health.db.enabled=false   // correct
//   management.health.datasource.enabled // WRONG - has no effect

go deeper

for a junior

Know the pattern management.health.<name>.enabled=false disables one check.

for a middle

Know the db-vs-datasource key trap and the defaults.enabled=false opt-in pattern.

for a senior

Separate the three levers (enabled / show-details / exposure) and choose disabling for non-critical deps to avoid false DOWN.

for a principal

Design a curated health surface: opt-in mode plus readiness groups so only truly critical checks affect LB membership.

## The toggle keys Every auto-configured built-in indicator is guarded by a property of the form: ``` management.health.<name>.enabled=true|false ``` where `<name>` is the indicator's registered name, not its class or bean name. The important ones for this leaf: - **`management.health.db.enabled`** — DataSourceHealthIndicator (note: `db`, *not* `datasource`). - **`management.health.diskspace.enabled`** — DiskSpaceHealthIndicator. - **`management.health.redis.enabled`** — RedisHealthIndicator. - **`management.health.ping.enabled`** — PingHealthIndicator. Setting one to `false` means the indicator bean is not registered / does not contribute; it simply vanishes from the aggregation and from the `components` section. ## Turning everything off (opt-in mode) ``` management.health.defaults.enabled=false ``` This flips the *default* for all auto-configured indicators to disabled. Nothing contributes unless you re-enable it explicitly. This is the pattern when you want a minimal, curated health surface: ``` management.health.defaults.enabled=false management.health.db.enabled=true management.health.ping.enabled=true ``` ## Why disable an indicator 1. **Cost / noise** — an indicator that hits a slow or non-critical dependency on every scrape. 2. **Wrong failure semantics** — e.g. you don't want a flaky non-critical Redis to mark the whole app DOWN and get it removed from the load balancer. Disabling (or moving it out of the readiness group) fixes that. 3. **Security / detail leakage** — reduce what's exposed. (Though `show-details` is the more direct lever there.) ## Three distinct concepts — don't conflate them - **`management.health.<name>.enabled`** — does the indicator *run and contribute*? - **`management.endpoint.health.show-details`** (`never`/`when-authorized`/`always`) — does the response *body reveal* per-component detail? - **`management.endpoints.web.exposure.include`** — is the `/health` endpoint *exposed over HTTP* at all? (`health` is exposed by default; most others aren't.) ## Gotchas - The datasource key is **`db`**, a classic wrong-guess in interviews. - Disabling an indicator does not delete the underlying bean (e.g. the DataSource) — only its health contribution. - With `management.health.defaults.enabled=false`, framework probe indicators like `livenessState`/`readinessState` (added when probes are enabled) may still behave per their own configuration; verify what your probe groups include.

  • What's the difference between management.health.redis.enabled=false and management.endpoint.health.show-details=never?
    The first removes the Redis indicator entirely so it never runs or affects the aggregate status. The second keeps all indicators running but hides the per-component breakdown from the response body, showing only the top-level status.
  • You set management.health.defaults.enabled=false but still see livenessState/readinessState components. Why?
    Those are added by the availability/probes support and are governed by the probes configuration and health groups, not solely by the defaults flag. Check management.endpoint.health.probes and your group includes.

saying these in an interview costs you the question

  • Using management.health.datasource.enabled (correct key is db)
  • Confusing enabled toggles with show-details or endpoint exposure
  • Thinking defaults.enabled=false disables the /health endpoint itself (it disables indicators, not the endpoint)

context

resolving links…