| Property | Purpose | Default |
|---|---|---|
logLevel | Global minimum log level | INFO |
disableSystemOut | Suppress stdout output | false |
disableLogging | Disable all logging and event processing | false |
compactLogFormat | One-line summaries instead of full JSON in stdout | false |
logLevelOverrides | Per-type/category log level overrides | {} |
detailedMatchFailures | Include per-field match failure reasons | true |
detailedVerificationFailures | Include per-field diff in verification failures | true |
failVerificationOnEvictedLog | Fail never() / atMost verifications when the event log has discarded entries | true |
launchUIForLogLevelDebug | Auto-open UI when log level is DEBUG | false |
metricsEnabled | Prometheus metrics endpoint | false |
slowRequestThresholdMillis | Flag forwarded requests slower than this threshold | 0 (disabled) |
metricsRequestDurationRouteLabels | Add per-HTTP-method labels to the request duration histogram | false |
The the minimum level of logs to record in the event log and to output to system out (if system out log output is not disabled). The lower the log level the more log entries will be captured, particularly at TRACE level logging.
Type: string Default: INFO
Allowed values: TRACE, DEBUG, INFO, WARN, ERROR, OFF (also accepts java.util.logging equivalents: FINEST, FINE, WARNING, SEVERE)
Java Code:
ConfigurationProperties.logLevel(String level)
System Property:
-Dmockserver.logLevel=...
Environment Variable:
MOCKSERVER_LOG_LEVEL=...
Property File:
mockserver.logLevel=...
Example:
-Dmockserver.logLevel="DEBUG"
Disable logging to the system output
Type: boolean Default: false
Java Code:
ConfigurationProperties.disableSystemOut(boolean disableSystemOut)
System Property:
-Dmockserver.disableSystemOut=...
Environment Variable:
MOCKSERVER_DISABLE_SYSTEM_OUT=...
Property File:
mockserver.disableSystemOut=...
Example:
-Dmockserver.disableSystemOut="true"
Disable all logging and processing of log events
Type: boolean Default: false
Java Code:
ConfigurationProperties.disableLogging(boolean disableLogging)
System Property:
-Dmockserver.disableLogging=...
Environment Variable:
MOCKSERVER_DISABLE_LOGGING=...
Property File:
mockserver.disableLogging=...
Example:
-Dmockserver.disableLogging="true"
When enabled, log messages written to stdout/SLF4J use a compact single-line format showing summary information (method, path, status code, expectation ID) instead of full JSON-serialized request and response details. This significantly reduces log noise, especially in CI/CD environments or when running many tests.
The dashboard UI, verification, and log retrieval APIs are not affected — they continue to show full details.
Type: boolean Default: false
Java Code:
ConfigurationProperties.compactLogFormat(boolean enable)
System Property:
-Dmockserver.compactLogFormat=...
Environment Variable:
MOCKSERVER_COMPACT_LOG_FORMAT=...
Property File:
mockserver.compactLogFormat=...
Example output comparison:
Verbose (default):
INFO - 50850 returning response:
{
"statusCode" : 200,
"body" : "{\"accessToken\":{...}}"
}
for request:
{
"method" : "POST",
"path" : "/oauth2/token",
"headers" : { ... }
}
from expectation:
a735b798-8aec-4c15-b264-c6d3c93fda1d
Compact:
INFO - 50850 returning response: 200 for request: POST /oauth2/token from expectation: a735b798-8aec-4c15-b264-c6d3c93fda1d
Example:
-Dmockserver.compactLogFormat="true"
Tip: combine with logLevelOverrides for maximum control. For example, enable compact format and suppress startup/shutdown noise:
-Dmockserver.compactLogFormat="true" -Dmockserver.logLevelOverrides='{"SERVER":"WARN"}'
Override the log level for specific categories of log events or individual log message types. This allows fine-grained control over log verbosity without changing the global log level.
Keys can be category group names or individual log message type names. When both are specified, the individual type override takes precedence over the category group override, which takes precedence over the global logLevel.
This setting affects stdout/SLF4J output and the dashboard UI. The internal event log (used for verification) is not affected.
Note: Overrides can only suppress log events that are already captured at the global logLevel. For example, with logLevel=WARN, setting {"EXPECTATION_MATCHED":"INFO"} will not cause INFO-level match events to appear, because they are not generated when the global level is WARN. To see more verbose events for a specific category, first set the global logLevel low enough (e.g., INFO or DEBUG), then use overrides to suppress the noisy categories.
Type: map (JSON object) Default: {} (empty, global logLevel applies to all categories)
Category Groups:
MATCHING | EXPECTATION_MATCHED, EXPECTATION_NOT_MATCHED, NO_MATCH_RESPONSE |
REQUEST_LIFECYCLE | RECEIVED_REQUEST, FORWARDED_REQUEST, EXPECTATION_RESPONSE, TEMPLATE_GENERATED |
EXPECTATION_MANAGEMENT | CREATED_EXPECTATION, UPDATED_EXPECTATION, REMOVED_EXPECTATION, CLEARED |
VERIFICATION | VERIFICATION, VERIFICATION_FAILED, VERIFICATION_PASSED, RETRIEVED |
SERVER | SERVER_CONFIGURATION, AUTHENTICATION_FAILED, OPENAPI_RESPONSE_VALIDATION_FAILED |
GENERAL | TRACE, DEBUG, INFO, WARN, ERROR, EXCEPTION |
Java Code:
ConfigurationProperties.logLevelOverrides(Map<String, String> overrides)
System Property:
-Dmockserver.logLevelOverrides=...
Environment Variable:
MOCKSERVER_LOG_LEVEL_OVERRIDES=...
Property File:
mockserver.logLevelOverrides=...
REST API:
PUT /mockserver/configuration {"logLevelOverrides": {"MATCHING": "WARN", "EXPECTATION_MATCHED": "INFO"}}
Example - suppress per-expectation match failure noise while keeping match successes:
-Dmockserver.logLevelOverrides='{"MATCHING":"WARN","EXPECTATION_MATCHED":"INFO"}'
Example - suppress all matching and expectation management logs:
MOCKSERVER_LOG_LEVEL_OVERRIDES='{"MATCHING":"WARN","EXPECTATION_MANAGEMENT":"WARN"}'
If true (the default) the log event recording that a request matcher did not match will include a detailed reason why each non matching field did not match. See Troubleshooting Matching for how to use this when debugging.
Type: boolean Default: true
Java Code:
ConfigurationProperties.detailedMatchFailures(boolean enable)
System Property:
-Dmockserver.detailedMatchFailures=...
Environment Variable:
MOCKSERVER_DETAILED_MATCH_FAILURES=...
Property File:
mockserver.detailedMatchFailures=...
Example:
-Dmockserver.detailedMatchFailures="false"
If true (the default) verification failure messages will include a detailed diff showing how each recorded request differed from the expected request. This makes it easier to identify why a verification failed by highlighting per-field mismatches between the expected and actual requests.
Disable this if verification failure messages are too verbose or if you prefer concise failure output.
Type: boolean Default: true
Java Code:
ConfigurationProperties.detailedVerificationFailures(boolean enable)
System Property:
-Dmockserver.detailedVerificationFailures=...
Environment Variable:
MOCKSERVER_DETAILED_VERIFICATION_FAILURES=...
Property File:
mockserver.detailedVerificationFailures=...
Example:
-Dmockserver.detailedVerificationFailures="false"
The event log holds at most maxLogEntries entries. Once it is full, the oldest entries are discarded to make room for new ones. Those discarded entries are gone — they can no longer be retrieved or verified.
This matters for verifications that assert something did not happen. If you call verify(request, never()) and the matching entries have been discarded, MockServer cannot tell the difference between "this request was never made" and "this request was made, but the record of it was thrown away". Previously it reported success, so a test asserting an endpoint was never called could quietly turn green simply because the log had filled up.
If true (the default) a verification that asserts an upper bound will fail, rather than pass, when the event log has discarded entries. The failure message tells you how many entries were discarded and the current maxLogEntries.
| Verification | Affected? | Why |
|---|---|---|
| never() | Yes | Asserts at most 0 calls |
| atMost(n) | Yes | Asserts at most n calls |
| exactly(n) | Yes | Asserts at most n calls |
| once() | Yes | Asserts exactly one call, so a discarded second call would go unnoticed |
| between(a, b) | Yes | Asserts at most b calls |
| atLeast(n) | No | No upper bound to violate |
| verify(request) (no times) | No | Defaults to atLeast(1) |
once() is worth calling out: it is a very common way to verify a request, and although it reads like "this happened", it actually asserts "this happened exactly once" — an upper bound. Discarding entries can only ever make the observed count too low, never too high, which is why lower-bound verifications are safe and upper-bound ones are not.
If a verification starts failing for this reason, the fix is usually one of:
maxLogEntries — note each request can log up to one entry per expectation, plus two, because every expectation that does not match logs an entry at INFO;INFO to stop non-matching expectations logging at all.Set to false to restore the previous behaviour, where these verifications could pass against an incomplete log.
Type: boolean Default: true
Java Code:
ConfigurationProperties.failVerificationOnEvictedLog(boolean enable)
System Property:
-Dmockserver.failVerificationOnEvictedLog=...
Environment Variable:
MOCKSERVER_FAIL_VERIFICATION_ON_EVICTED_LOG=...
Property File:
mockserver.failVerificationOnEvictedLog=...
Example:
-Dmockserver.failVerificationOnEvictedLog="false"
If true (default false) the ClientAndServer constructor or static factory methods will open the UI in the default browser when the log level is set to DEBUG.
Type: boolean Default: false
Java Code:
ConfigurationProperties.launchUIForLogLevelDebug(boolean enable)
System Property:
-Dmockserver.launchUIForLogLevelDebug=...
Environment Variable:
MOCKSERVER_LAUNCH_UI_FOR_LOG_LEVEL_DEBUG=...
Property File:
mockserver.launchUIForLogLevelDebug=...
Example:
-Dmockserver.launchUIForLogLevelDebug="false"
Enable the recording of metrics for different activities within MockServer, these are exposed via /mockserver/metrics in prometheus format
Type: boolean Default: false
Java Code:
ConfigurationProperties.metricsEnabled(boolean enable)
System Property:
-Dmockserver.metricsEnabled=...
Environment Variable:
MOCKSERVER_METRICS_ENABLED=...
Property File:
mockserver.metricsEnabled=...
Example:
-Dmockserver.metricsEnabled="true"
Threshold in milliseconds for flagging slow forwarded requests. When a forwarded request's total round-trip time exceeds this value, MockServer emits a WARN-level log entry and increments the mock_server_slow_requests_total Prometheus counter (when metrics are enabled). This is useful for detecting intermittently slow upstream services without scanning every recorded request manually.
Set to 0 to disable slow-request detection. See Network Latency Debugging for usage examples.
Type: long Default: 0 (disabled)
Java Code:
ConfigurationProperties.slowRequestThresholdMillis(long milliseconds)
System Property:
-Dmockserver.slowRequestThresholdMillis=...
Environment Variable:
MOCKSERVER_SLOW_REQUEST_THRESHOLD_MILLIS=...
Property File:
mockserver.slowRequestThresholdMillis=...
Example:
-Dmockserver.slowRequestThresholdMillis="500"
When enabled, MockServer registers an additional Prometheus histogram mock_server_request_duration_by_method_seconds with a method label for the HTTP method (GET, POST, PUT, etc.). This lets you compute per-method latency percentiles in your monitoring system. Cardinality is bounded to the set of standard HTTP methods.
Requires metricsEnabled to be true. See Network Latency Debugging for Prometheus query examples.
Type: boolean Default: false
Java Code:
ConfigurationProperties.metricsRequestDurationRouteLabels(boolean enable)
System Property:
-Dmockserver.metricsRequestDurationRouteLabels=...
Environment Variable:
MOCKSERVER_METRICS_REQUEST_DURATION_ROUTE_LABELS=...
Property File:
mockserver.metricsRequestDurationRouteLabels=...
Example:
-Dmockserver.metricsRequestDurationRouteLabels="true"
Register a custom callback that receives every log event generated by MockServer. This is useful for integrating MockServer logging with external systems (e.g. forwarding events to a monitoring tool, custom test reporting, or capturing specific events programmatically during tests).
This feature is programmatic only — there is no system property or environment variable equivalent because the listener is a Java callback.
Java Code:
Configuration.logEventListener(Consumer<LogEntry> listener)
ClientAndServer.setLogEventListener(Consumer<LogEntry> listener)
Example:
ClientAndServer mockServer = ClientAndServer.startClientAndServer(1080);
mockServer.setLogEventListener(logEntry -> {
System.out.println("Event: " + logEntry.getType() + " - " + logEntry.getTimestamp());
});