Walk through what /actuator/scheduledtasks, /actuator/caches, /actuator/env, and /actuator/configprops expose, and their notable operations and behaviors.

seniorshould knowfreq 30%

answer

scheduledtasks: cron/fixedDelay/fixedRate/custom groups
caches: list + DELETE to evict (writable!)
env: property sources in precedence order; /env/{name}
configprops: @ConfigurationProperties bound values
env+configprops sanitize by default (Boot 3 masks all)

basics

~20 s

/scheduledtasks lists all @Scheduled tasks grouped by trigger type (cron/fixedRate/fixedDelay/custom). /caches lists Spring caches by cache manager, and supports DELETE to clear them. /env shows the Environment's property sources and values. /configprops shows @ConfigurationProperties beans and their bound values. env and configprops mask sensitive values by default.

solid answer

~40 s

/actuator/scheduledtasks (ScheduledTasksEndpoint) inventories every scheduled task registered via @Scheduled or ScheduledTaskRegistrar, grouped into cron, fixedDelay, fixedRate, and custom, each showing the target runnable method and timing. /actuator/caches (CachesEndpoint) lists caches discovered from every CacheManager, keyed by cache name and manager; it also supports DELETE /actuator/caches (clear all) and DELETE /actuator/caches/{name} (evict one) — a rare write Actuator operation. /actuator/env (EnvironmentEndpoint) exposes the ConfigurableEnvironment: each PropertySource and its properties, active profiles, plus GET /actuator/env/{propertyName} for one key with its resolution across sources. /actuator/configprops (ConfigurationPropertiesReportEndpoint) lists each @ConfigurationProperties bean, its prefix, and the currently bound values. Both env and configprops sanitize values by default — in Spring Boot 3 values are masked (******) unless show-values is raised — because they can leak passwords, keys, and connection strings.

`/actuator/scheduledtasks` (`ScheduledTasksEndpoint`) inventories every scheduled task registered via `@Scheduled` or `ScheduledTaskRegistrar`, grouped into `cron`, `fixedDelay`, `fixedRate`, and `custom`, each showing the target `runnable` method and timing. `/actuator/caches` (`CachesEndpoint`) lists caches discovered from every `CacheManager`, keyed by cache name and manager; it also supports `DELETE /actuator/caches` (clear all) and `DELETE /actuator/caches/{name}` (evict one) — a rare *write* Actuator operation. `/actuator/env` (`EnvironmentEndpoint`) exposes the `ConfigurableEnvironment`: each `PropertySource` and its properties, active profiles, plus `GET /actuator/env/{propertyName}` for one key with its resolution across sources. `/actuator/configprops` (`ConfigurationPropertiesReportEndpoint`) lists each `@ConfigurationProperties` bean, its prefix, and the currently bound values. Both `env` and `configprops` **sanitize values by default** — in Spring Boot 3 values are masked (`******`) unless `show-values` is raised — because they can leak passwords, keys, and connection strings.

code

java · 33 lines

java

// A @Scheduled job appears under /actuator/scheduledtasks -> cron
import org.springframework.scheduling.annotation.Scheduled;
import org.springframework.stereotype.Component;

@Component
public class ReportJob {
    @Scheduled(cron = "0 0 2 * * *")   // shows up as expression "0 0 2 * * *"
    public void nightly() { /* ... */ }

    @Scheduled(fixedDelay = 5000)      // shows up under fixedDelay, interval 5000
    public void poll() { /* ... */ }
}

// Evict a single cache at runtime (a rare WRITE Actuator op):
//   curl -X DELETE http://localhost:8080/actuator/caches/orders

// Reveal env/configprops values only for authorized callers, and mask a
// custom-sensitive key, via a SanitizingFunction bean:
import org.springframework.boot.actuate.endpoint.SanitizableData;
import org.springframework.boot.actuate.endpoint.SanitizingFunction;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration
class SanitizerConfig {
    @Bean
    SanitizingFunction maskInternalToken() {
        return (SanitizableData data) ->
            data.getKey() != null && data.getKey().contains("internal-token")
                ? data.withValue("******")
                : data;
    }
}

go deeper

for a junior

Name each endpoint's purpose: scheduled jobs, caches, environment properties, bound config properties.

for a middle

Describe the response structure and that env/configprops mask sensitive values.

for a senior

Explain env precedence resolution, configprops bound-vs-raw distinction, the DELETE cache ops, and Boot 3's mask-all default.

for a principal

Own the security posture: which of these are ever exposed where, SanitizingFunction policy, and treating caches DELETE as a guarded operation.

This group covers runtime inventory (scheduledtasks, caches) and configuration introspection (env, configprops).

/actuator/scheduledtasks — ScheduledTasksEndpoint. Lists tasks scheduled by Spring's @EnableScheduling/@Scheduled machinery (and anything registered via SchedulingConfigurer/ScheduledTaskRegistrar). Response groups them:

json

{
  "cron":       [ { "runnable": { "target": "com.acme.ReportJob.nightly" }, "expression": "0 0 2 * * *" } ],
  "fixedDelay": [ { "runnable": { "target": "com.acme.Poller.poll" }, "initialDelay": 0, "interval": 5000 } ],
  "fixedRate":  [ ... ],
  "custom":     [ ... ]
}

Great for confirming a job is actually registered and on the schedule you think. Note it lists definitions, not run history or next-fire time.

/actuator/caches — CachesEndpoint. Enumerates caches from all CacheManager beans:

json

{ "cacheManagers": { "cacheManager": { "caches": {
    "orders":  { "target": "java.util.concurrent.ConcurrentHashMap" },
    "users":   { "target": "..." } } } } }

Uniquely, it supports write operations: DELETE /actuator/caches clears every cache; DELETE /actuator/caches/{name} evicts one (optionally ?cacheManager=... to disambiguate when a name exists in multiple managers). This makes it operationally handy for busting a stale cache in prod without a redeploy — but it's a mutating, potentially disruptive action, so guard it. (Most Actuator endpoints are read-only; caches, loggers, and shutdown are the notable writable ones.)

/actuator/env — EnvironmentEndpoint. Reflects Spring's ConfigurableEnvironment — the layered configuration model. It returns activeProfiles and propertySources in precedence order (command-line args, OS env vars, application-{profile}.yml, application.yml, defaults, etc.), each with its properties. GET /actuator/env/{name} shows a single property and how it resolves across sources (which source wins). This is the tool for 'what value is this property actually resolving to and from where?' — indispensable when an override isn't taking effect.

/actuator/configprops — ConfigurationPropertiesReportEndpoint. Complements env: instead of raw property sources it shows the bound view — every @ConfigurationProperties bean, its prefix, and the resolved object graph of values after relaxed binding and type conversion. So you see the effective, typed configuration your beans received (e.g. spring.datasource → the DataSourceProperties values). Use it to verify binding worked as intended.

Sanitization (the key gotcha). Both env and configprops can leak secrets — DB passwords, API keys, tokens, connection strings. To mitigate, values are sanitized. Historically (Boot 2.x) only keys matching patterns like password, secret, key, token, credentials, vcap_services were masked to ******. Spring Boot 3 tightened this: by default all values are masked unless you opt in via management.endpoint.env.show-values / management.endpoint.configprops.show-values set to WHEN_AUTHORIZED or ALWAYS. You can customize masking with a SanitizingFunction bean (the Sanitizer SPI). Even so, exposing env/configprops publicly is dangerous reconnaissance-wise and generally kept behind auth or unexposed.

Cross-cutting notes.

None of these four are web-exposed by default (only health is) — expect 404 until exposed.
env/configprops/scheduledtasks/beans reflect the startup configuration snapshot; caches reflects live cache managers and can mutate.
configprops only covers beans annotated @ConfigurationProperties; a @Value-injected field won't appear there (it would in env).

When to use. env → 'which value/source wins?'; configprops → 'did binding produce the object I expected?'; scheduledtasks → 'is my job registered on the right schedule?'; caches → 'list or bust caches at runtime'.

This group covers runtime inventory (`scheduledtasks`, `caches`) and configuration introspection (`env`, `configprops`). **`/actuator/scheduledtasks` — `ScheduledTasksEndpoint`.** Lists tasks scheduled by Spring's `@EnableScheduling`/`@Scheduled` machinery (and anything registered via `SchedulingConfigurer`/`ScheduledTaskRegistrar`). Response groups them: ```json { "cron": [ { "runnable": { "target": "com.acme.ReportJob.nightly" }, "expression": "0 0 2 * * *" } ], "fixedDelay": [ { "runnable": { "target": "com.acme.Poller.poll" }, "initialDelay": 0, "interval": 5000 } ], "fixedRate": [ ... ], "custom": [ ... ] } ``` Great for confirming a job is actually registered and on the schedule you think. Note it lists *definitions*, not run history or next-fire time. **`/actuator/caches` — `CachesEndpoint`.** Enumerates caches from all `CacheManager` beans: ```json { "cacheManagers": { "cacheManager": { "caches": { "orders": { "target": "java.util.concurrent.ConcurrentHashMap" }, "users": { "target": "..." } } } } } ``` Uniquely, it supports **write operations**: `DELETE /actuator/caches` clears every cache; `DELETE /actuator/caches/{name}` evicts one (optionally `?cacheManager=...` to disambiguate when a name exists in multiple managers). This makes it operationally handy for busting a stale cache in prod without a redeploy — but it's a mutating, potentially disruptive action, so guard it. (Most Actuator endpoints are read-only; `caches`, `loggers`, and `shutdown` are the notable writable ones.) **`/actuator/env` — `EnvironmentEndpoint`.** Reflects Spring's `ConfigurableEnvironment` — the layered configuration model. It returns `activeProfiles` and `propertySources` in **precedence order** (command-line args, OS env vars, `application-{profile}.yml`, `application.yml`, defaults, etc.), each with its properties. `GET /actuator/env/{name}` shows a single property and how it resolves across sources (which source wins). This is the tool for 'what value is this property *actually* resolving to and from where?' — indispensable when an override isn't taking effect. **`/actuator/configprops` — `ConfigurationPropertiesReportEndpoint`.** Complements `env`: instead of raw property sources it shows the *bound* view — every `@ConfigurationProperties` bean, its `prefix`, and the resolved object graph of values after relaxed binding and type conversion. So you see the effective, typed configuration your beans received (e.g. `spring.datasource` → the `DataSourceProperties` values). Use it to verify binding worked as intended. **Sanitization (the key gotcha).** Both `env` and `configprops` can leak secrets — DB passwords, API keys, tokens, connection strings. To mitigate, values are **sanitized**. Historically (Boot 2.x) only keys matching patterns like `password`, `secret`, `key`, `token`, `credentials`, `vcap_services` were masked to `******`. **Spring Boot 3 tightened this: by default *all* values are masked** unless you opt in via `management.endpoint.env.show-values` / `management.endpoint.configprops.show-values` set to `WHEN_AUTHORIZED` or `ALWAYS`. You can customize masking with a `SanitizingFunction` bean (the `Sanitizer` SPI). Even so, exposing `env`/`configprops` publicly is dangerous reconnaissance-wise and generally kept behind auth or unexposed. **Cross-cutting notes.** - None of these four are web-exposed by default (only `health` is) — expect 404 until exposed. - `env`/`configprops`/`scheduledtasks`/`beans` reflect the startup configuration snapshot; `caches` reflects live cache managers and can mutate. - `configprops` only covers beans annotated `@ConfigurationProperties`; a `@Value`-injected field won't appear there (it would in `env`). **When to use.** `env` → 'which value/source wins?'; `configprops` → 'did binding produce the object I expected?'; `scheduledtasks` → 'is my job registered on the right schedule?'; `caches` → 'list or bust caches at runtime'.

You set a property via an environment variable but the app still uses the YAML value. Which endpoint diagnoses this and how?
GET /actuator/env/{propertyName}. It lists every property source that defines the key in precedence order and which one resolves. If the OS-env source shows the value but a higher-precedence source overrides it — or the env var name/relaxed-binding form is wrong — the report reveals it.
Why is /actuator/caches notable among Actuator endpoints, and what's the risk?
It's one of the few endpoints that support write operations — DELETE clears/evicts caches at runtime. That's operationally useful for busting stale data, but it's disruptive and unauthenticated exposure could let anyone flush your caches, so it must be secured.

saying these in an interview costs you the question

Claiming /actuator/env shows all secret values in plaintext by default
Thinking every Actuator endpoint is read-only (caches supports DELETE)
Saying scheduledtasks shows run history / next-fire times
Believing @Value-injected properties appear under configprops

Walk through what /actuator/scheduledtasks, /actuator/caches, /actuator/env, and /actuator/configprops expose, and their notable operations and behaviors.

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~3 min

▾common follow-ups2 questions

▾red flags4 flags

§ context

▾related questions4 questions

▾related topics3 topics

answer

go deeper

context