Spring Boot inspector

Conditions (/actuator/conditions, the --debug report as JSON) — every auto-configuration, its nested configurations and @Bean methods, applied or not, with each condition’s result. Group by auto-configuration or by area (data access, web, actuator, messaging…), filter to what didn’t apply, and search for a class, a condition or a property. A failed condition is turned into the thing to do: add spring-boot-starter-amqp to bring in RabbitTemplate, set spring.h2.console.enabled=true, your bean 'shopObjectMapper' took its place. A list at the bottom explains each condition type in the report.

Beans (/actuator/beans) — search by name, type or resource; your own beans are marked. Pick one to see its type, scope, what defined it (component scan, a @Bean method, an auto-configuration), what it uses and what uses it, drawn as a graph one or two hops out. With nothing picked, the graph shows your beans and what they depend on. Dependency cycles are flagged (Boot 2.6+ refuses them by default). Parent contexts are shown when there are several.

Environment (/actuator/env, or /actuator/env/<name> for one key) — the active profiles, every property source in precedence order, and every key with the value that wins and where it came from. Click a key to see every source that sets it, the hidden ones struck through. Keys are matched the way Boot binds them, so shop.maxBasket in a file and SHOP_MAX_BASKET in the environment are one key. Masked values () are shown as masked; values that look like passwords but aren’t masked are called out.

Config props (/actuator/configprops) — every @ConfigurationProperties bean with its bound values in kebab-case and the origin of each one (file and line, environment variable, command line), or none when it’s a default.

Mappings (/actuator/mappings) — the request mappings as a table: methods, paths, consumes / produces / params / headers and the handler method, split into your routes, actuator, static resources and error handling; then the servlets and filters. WebFlux handlers are read too.

Metrics & health — /actuator/health as a tree with each component’s details, the meter names from /actuator/metrics grouped by prefix (click one to copy its curl command), and the numbers from any /actuator/metrics/<name> you paste, with the mean for timers.

Properties ↔ YAML — converts both ways. #--- documents in a .properties file become --- YAML documents (with spring.config.activate.on-profile carried across), [0] indexes become lists, bracketed map keys like [/api/**] are kept and quoted. Going to YAML, values YAML 1.1 would change are quoted: NO would become false, 0123 an octal number, 1.10 the number 1.1 and 12:30 the base-60 number 750. Going to properties, non-ASCII characters are written as \uXXXX, because Boot reads .properties files as ISO-8859-1.

Check config — paste application.properties or application.yml. It checks the common server., spring.datasource. (with Hikari), spring.jpa., management. and logging. keys: types, enums, durations and data sizes; keys renamed or removed between 2.x and 3.x (spring.redis., server.tomcat.max-threads, logging.file…); near-misses (did you mean show-details?); Hikari’s own limits, which it otherwise fixes silently with a log line (max-lifetime under 30 s, keepalive-time at or above max-lifetime, leak detection under 2 s, and durations like 30s that Hikari’s millisecond setters can’t take); profile rules (spring.profiles.include inside a profile document stops Boot starting); and settings that leak data (exposure.include: "", show-values: always, stack traces in error pages). It also lists what each recognised key does with its default. When the config sets a Hikari pool, *Size this pool opens it in the connection pool planner.

Relaxed binding — type a property name, or an environment variable, and see every form: canonical kebab-case, camelCase, the environment variable and its legacy form, -D, command-line, SPRING_APPLICATION_JSON and YAML. The rules underneath explain what @ConfigurationProperties accepts, what @Value doesn’t, and why LOGGING_LEVEL_ORG_HIBERNATE_SQL doesn’t reach the org.hibernate.SQL logger (I checked: on the example app it set org.hibernate.sql, a different logger).

In 3.x /env and /configprops mask every value unless management.endpoint.env.show-values (and configprops.show-values) say otherwise, and always then shows everything, passwords included. 2.x showed values and masked keys that looked like secrets.

/health in 2.0 and 2.1 nests components under details; 2.2+ uses components. Both read.

1.x had /autoconfig instead of /conditions with a flatter shape; it reads, but 1.x /mappings and /beans do not.

The converter and checker follow 2.4+ config-file processing (spring.config.activate.on-profile and #---); the checker flags the older spring.profiles document key.

The checker knows about 180 common keys, not the whole of Boot’s configuration metadata, so it says "not in this checker’s list" rather than "wrong" for keys it doesn’t know. Boot itself ignores unknown keys.

Line numbers for YAML findings are found by searching the text, so a repeated key name can point at the wrong line.

The Conditions report has short class names only (no packages), so areas are guessed from the names.