Karate automatic request/response logging limits for failed steps

Short answer

Karate's failure logging is intentionally verbose and intentionally naive: when a step fails, it dumps the full request and response for any method that carries a body, it does not mask headers or secrets, and there is no built-in size threshold that truncates large payloads. The only global switch is karate.log (plus the logPrettyRequest/logPrettyResponse configure keys); finer control requires a log modifier hook in newer 1.x releases.

The three open questions

Which methods log bodies?

There is no verb-based restriction. Karate logs whatever body exists: POST, PUT, PATCH, and DELETE-with-body all appear in full. GET and HEAD simply have no body to log, so they look "excluded" but aren't. If you send a multipart or binary body on any verb, assume it will be written to the log on failure.

Are secrets masked?

No. Authorization headers, cookies, and API keys appear in plain text in console output, and—more importantly—they are embedded into the cucumber-json and HTML reports under target/karate-reports. That means secrets persist in CI artifacts long after the console scrolls away. Treat any failure log as a secret-leak surface and scrub artifacts accordingly.

Is there a size limit or truncation?

There is no built-in threshold. A 50 MB response body that fails an assertion will be logged in full, which can flood CI logs and balloon report files. The practical mitigations are to disable pretty logging for those specific calls, or to suppress logging globally with -Dkarate.log=false—but note that this removes debugging context for all failures, which is usually too blunt.

What you can actually do

1. Keep secrets out of logged headers. Build headers via a JS function in karate-config.js so tokens are injected at call time rather than hardcoded, and prefer short-lived tokens in test environments.
2. Use a log modifier if your version supports it. Later Karate 1.x releases expose a logModifier configuration hook that lets you transform or redact request/response content before it is written. This is the supported way to mask Authorization values. This API is version-sensitive—confirm it exists in your exact release before relying on it.
3. Gate verbosity per environment. Set logPrettyRequest/logPrettyResponse to false in CI for suites that handle large payloads, and keep pretty logging on locally.

Verify against your version

Behavior here has shifted across releases, so don't trust any summary (including this one) over a direct test. Run a deliberately failing scenario that sends an Authorization header and a large POST body, then inspect both the console and target/karate-reports:

mvn test -Dtest=YourFailingTest -Dkarate.env=qa

Check three things: whether the body appears in full, whether the token is readable, and how large the generated report files are. Then apply a logModifier masking function (if supported) and re-run to confirm redaction actually reaches the report files, not just stdout.

Caveats

• The karate.env value printed in logs is helpful for correlation but also leaks environment naming into artifacts—fine for most teams, worth knowing for regulated ones.
• Exact logModifier availability and report-verbosity options vary by Karate 1.x minor version. If the masking behavior is load-bearing for compliance, verify it on your pinned version rather than after an upgrade.