Introduction

If a Spring Boot error response includes a trace field, that field is coming from the application's error rendering layer, not from ResponseStatusException alone. In most cases, the quickest fix is to disable stack-trace inclusion in error responses through configuration. If you need stricter control, customize the error attributes or your exception handling response shape directly.

The Fast Configuration Fix

Spring Boot exposes a property for stack-trace inclusion:

server.error.include-stacktrace=never

With that setting, the default error payload no longer includes the trace in normal responses.

There are also environments where teams allow traces conditionally during development, but the production-safe default is still to keep them out of client responses.

This is why the same exception can look different between local development and production. The exception type did not change; the server's error-rendering policy did.

This is usually the right production default because stack traces are:

• Noisy for API clients
• Potentially sensitive
• Larger than necessary for standard error handling

Why ResponseStatusException Still Shows It

Throwing ResponseStatusException controls the HTTP status and reason, but the final JSON body is often produced by the framework's error-handling infrastructure. If that infrastructure is configured to include traces, you will still see them regardless of the exception type.

Example:

throw new ResponseStatusException(HttpStatus.BAD_REQUEST, "Invalid request");

That does not by itself mean the response must contain a stack trace. The stack trace appears only if the error renderer is told to expose it.

Customize the Error Body

If you want tighter control, define custom error attributes:

1import org.springframework.boot.web.error.ErrorAttributeOptions;
2import org.springframework.boot.web.servlet.error.DefaultErrorAttributes;
3import org.springframework.stereotype.Component;
4import org.springframework.web.context.request.WebRequest;
5
6import java.util.Map;
7
8@Component
9public class ApiErrorAttributes extends DefaultErrorAttributes {
10    @Override
11    public Map<String, Object> getErrorAttributes(
12            WebRequest webRequest,
13            ErrorAttributeOptions options) {
14
15        options = options.excluding(ErrorAttributeOptions.Include.STACK_TRACE);
16        return super.getErrorAttributes(webRequest, options);
17    }
18}

This lets you keep the default error pipeline while removing the stack trace deliberately.

Another Option: Custom Exception Responses

For API-first services, many teams skip the default error shape entirely and use @ControllerAdvice to return a custom payload:

1import org.springframework.http.HttpStatus;
2import org.springframework.http.ResponseEntity;
3import org.springframework.web.bind.annotation.ControllerAdvice;
4import org.springframework.web.bind.annotation.ExceptionHandler;
5import org.springframework.web.server.ResponseStatusException;
6
7import java.util.Map;
8
9@ControllerAdvice
10public class ApiExceptionHandler {
11    @ExceptionHandler(ResponseStatusException.class)
12    public ResponseEntity<Map<String, Object>> handle(ResponseStatusException ex) {
13        return ResponseEntity
14                .status(ex.getStatusCode())
15                .body(Map.of(
16                        "status", ex.getStatusCode().value(),
17                        "message", ex.getReason()
18                ));
19    }
20}

This gives you full control over what the client sees.

It also makes your API contract independent from framework defaults, which is useful if clients depend on a stable error schema across framework upgrades.

That approach is especially attractive when you want a stable API error contract instead of the framework's default error JSON shape.

Common Pitfalls

• Blaming ResponseStatusException itself when the trace is really added by the global error renderer.
• Leaving stack traces enabled in production responses.
• Customizing exception handling in one place while default error attributes still leak traces elsewhere.
• Treating the problem as serialization-only when it is really an error-pipeline configuration issue.

Summary

• The trace field is usually controlled by Spring Boot error rendering, not by ResponseStatusException alone.
• 'server.error.include-stacktrace=never is the simplest way to remove it.'
• For stronger control, customize ErrorAttributes or return your own API error shape.
• Production APIs should rarely expose stack traces to clients.
• Clean error responses come from controlling the whole error pipeline, not only the exception type.

That is usually the fastest way to reason about the problem in production systems. The exception class is only one piece of the pipeline. The renderer is the other.