Suggestion: Provide an option for minimal stacktrace output in Spring Boot error logging

[dhruv-15-03]

Feature Request: Minimal Startup Error Output for Easier Debugging

Description

When an application fails to start, Spring Boot currently prints the entire exception chain with very long stacktraces (often dozens of lines). While this is thorough and valuable for advanced debugging, it can be overwhelming and noisy for most developers, especially when the actionable cause is buried deep in the logs.

For example, a simple misconfiguration in the datasource URL currently produces output spanning 50+ lines, even though the key message is just:

Caused by: java.lang.RuntimeException: Driver com.mysql.cj.jdbc.Driver claims to not accept jdbcUrl, ${DB_URL}

Proposal

Introduce a configuration property (e.g., spring.main.minimal-errors=true) that changes startup error reporting to display a minimal root cause summary (3–5 lines). Developers could still opt in to the full stacktrace by enabling debug mode (--debug) or via a property (e.g., spring.main.full-errors=true).

This approach would follow the model of other developer tools (e.g., Maven/Gradle), which default to concise error summaries but provide full logs on demand.

Benefits

• Improves developer experience: Makes it faster to identify the actual cause of startup failures.
• Reduces noise: Cleaner console output, especially helpful in CI/CD logs.
• Beginner-friendly: Lowers the intimidation factor for new developers learning Spring Boot.
• Optional behavior: Full stacktraces remain available when needed.

Example of Expected Minimal Output

Application failed to start

Reason:
Driver com.mysql.cj.jdbc.Driver claims to not accept jdbcUrl, ${DB_URL}

Fix:
Check your datasource URL configuration in application.properties

Notes

• This would be an optional feature, not a breaking change.
• Could default to "full error output," but allow toggling to "minimal" mode.
• Would be consistent with Spring Boot’s philosophy of developer friendliness and convention over configuration.

---

🙏 Thanks for considering this! A minimal error reporting option would make Spring Boot startup failures much easier to digest while still preserving the ability to view full stacktraces when needed.

[nosan]

I think what you actually asked for already exists and can be configured with the logging.exception-conversion-word property.

For example, with the following configuration: logging.exception-conversion-word=%xEx{short}

The output will be:

java.lang.IllegalStateException: Service
	at com.example.demo.Service.throwException(Service.java:17) ~[main/:na]
Caused by: java.lang.IllegalStateException: Service 1
	at com.example.demo.Service1.threwException(Service1.java:14) ~[main/:na]

Using logging.exception-conversion-word=%xEx{10}

The output will print up to 10 lines for each exception.

java.lang.IllegalStateException: Service
	at com.example.demo.Service.throwException(Service.java:17) ~[main/:na]
	at com.example.demo.DemoApplication.main(DemoApplication.java:15) ~[main/:na]
Caused by: java.lang.IllegalStateException: Service 1
	at com.example.demo.Service1.threwException(Service1.java:14) ~[main/:na]
	at com.example.demo.Service1.threwException(Service1.java:16) ~[main/:na]
	at com.example.demo.Service1.threwException(Service1.java:16) ~[main/:na]
	at com.example.demo.Service1.threwException(Service1.java:16) ~[main/:na]
	at com.example.demo.Service1.threwException(Service1.java:16) ~[main/:na]
	at com.example.demo.Service1.threwException(Service1.java:16) ~[main/:na]
	at com.example.demo.Service1.threwException(Service1.java:16) ~[main/:na]
	at com.example.demo.Service1.threwException(Service1.java:16) ~[main/:na]
	at com.example.demo.Service1.threwException(Service1.java:16) ~[main/:na]
	at com.example.demo.Service1.threwException(Service1.java:16) ~[main/:na]

[bclozel]

Indeed, this approach is much more flexible and leaves more space for different opinions on the matter. spring.main.full-errors=true and spring.main.minimal-errors=true would probably in the wrong namespace (it doesn't mention logging so discoverability is not great) and would greatly limit developers to very specific opinions.

[wilkinsona]

We also have the concept of failure analysis for specific well-known exceptions and produces output similar to the above example of expected minimal output. You can add your own FailureAnalyzers for exceptions that Boot's do not already cover.