Introduction

Spring Boot's auto-configuration report explains why configuration classes matched or did not match during startup. It is one of the best troubleshooting tools when a bean appears unexpectedly, a feature is missing, or you want to understand which classpath conditions made Spring Boot wire the application the way it did.

Enable the Report With Debug Mode

The simplest way to show the report is to enable Boot's debug mode. You can do that from configuration or from the command line.

In application.properties:

debug=true

Or on the command line:

java -jar app.jar --debug

When debug mode is active, Spring Boot prints a condition evaluation report during startup.

Read the Positive and Negative Matches

The report is not just a wall of text. It is divided into useful sections:

• positive matches, which explain which auto-configurations applied
• negative matches, which explain which conditions failed
• unconditional classes, which are always loaded

That structure is what makes the report so helpful. You are not merely told that something happened. You are shown why it happened.

Example of the Kind of Output You Are Looking For

A report entry often looks conceptually like this:

1Positive matches:
2-----------------
3DataSourceAutoConfiguration matched:
4   - @ConditionalOnClass found required classes
5
6Negative matches:
7-----------------
8MongoAutoConfiguration did not match:
9   - @ConditionalOnClass did not find required class 'com.mongodb.client.MongoClient'

This tells you which condition was satisfied or missing, which is often enough to explain surprising startup behavior.

Use the Report to Debug Missing or Unexpected Beans

Typical use cases include:

• a data source was configured even though you did not expect one
• security auto-configuration activated unexpectedly
• a feature did not start because a required class or property was missing
• two possible auto-configurations are competing and only one matched

Instead of guessing, the report shows which conditions were evaluated and why they passed or failed.

Actuator Gives a Runtime View Too

If you use Spring Boot Actuator, the /actuator/conditions endpoint can provide similar information at runtime.

management.endpoints.web.exposure.include=conditions

That is useful when you want the same kind of visibility without depending only on startup logs. It also helps when the startup output is too noisy or the environment makes log capture inconvenient.

Keep the Report for Diagnosis, Not for Normal Production Logging

The auto-configuration report is extremely useful during local development, debugging, and test-environment investigation. It is not something most teams leave enabled permanently in production logs.

A good pattern is to turn it on when you are diagnosing a startup problem, collect the evidence you need, and then turn it off again so logs return to their normal signal-to-noise level.

Common Patterns It Helps Expose

The report is especially good at revealing condition-based issues such as:

• classpath differences between environments
• missing optional dependencies
• property values disabling features unexpectedly
• multiple starters pulling in overlapping configuration paths

When Boot does something that feels mysterious, the condition report is usually where the mystery becomes concrete.

Common Pitfalls

• Looking only at positive matches and ignoring why something else failed to configure.
• Enabling debug mode and then not reading the condition sections carefully.
• Assuming the report is a production feature toggle rather than a diagnostic tool.
• Forgetting Actuator can expose similar information at runtime.
• Guessing at auto-configuration causes before checking the actual condition evaluation report.

Summary

• Enable the auto-configuration report with debug=true or the --debug startup flag.
• The report explains which auto-configurations matched and which did not.
• It is one of the best tools for debugging unexpected or missing Spring Boot behavior.
• Actuator can provide a similar runtime view through the conditions endpoint.
• Use the report intentionally during troubleshooting rather than leaving it on everywhere by default.