MockServer UI

MockServer has a real-time dashboard that gives you full visibility into what MockServer is doing. The following views are available from the navigation bar at the top of the page:

• Get Started — guided first-run view: import an OpenAPI spec, set up a proxy, try a quick-start recipe, or browse the docs
• Dashboard — four panels showing log messages, active expectations, received requests, and proxied requests
• Traffic — every captured request in a master list, with a rich detail pane on the right for LLM and MCP traffic, a Replay button to re-issue a captured request, and a Compare toggle to diff two requests field-by-field
• Trace — related requests grouped into swim-lanes — including LLM agent runs — to follow a multi-step flow end to end, plus a Compare tab for diffing two captured runs side-by-side
• Breakpoints — pause, inspect, and manipulate live stream frames (SSE, gRPC, WebSocket, GraphQL subscription) and request/response exchanges; see Interactive Breakpoints
• Audit — a chronological trail of control-plane mutations (who changed what expectation, configuration, or server state), separate from the request/response log
• Mocks — create or edit expectations of every kind (HTTP, gRPC, DNS, MCP, LLM), import them (Expectation JSON, OpenAPI, WSDL, HAR, Postman), and insert engine-aware template snippets without writing any code
• Scenarios — view and drive the state machines your scenario-bound mocks step through, with a diagram of the states a scenario has actually visited
• Chaos — configure and inject HTTP, gRPC, and TCP faults that apply to all forwarded requests to a given upstream host or service, define multi-stage chaos experiments that progress through those faults automatically over time, and simulate a Kubernetes node drain / Spot reclamation with the preemption simulator. The HTTP fault set covers error responses, dropped connections, latency, body corruption, slow-response chunking, quotas/rate limits, count and time windows, gradual degradation, and a GraphQL error envelope, with a TTL so chaos auto-expires
• Performance — create and run load scenarios: a stage-builder for VU and arrival-rate stages with ramp curves, live run status (current stage, target, active VUs), and a combined toggleable latency/throughput metrics graph
• LLM Optimise — analyse captured LLM traffic for cost, token, latency, and prompt-hygiene opportunities, and export an optimisation brief
• MCP Server Health — per-MCP-server latency and error rate for the MCP servers your proxied tools call, worst-first, so you can see which server is the real bottleneck
• Async — inspect the AsyncAPI broker mock: loaded spec, active channels, and messages recorded from broker subscriptions
• gRPC — list mocked gRPC services and methods loaded from protobuf descriptors, with streaming kind and health serving status
• Library — import expectations, export traffic, and manage cassette files, WASM modules, and gRPC descriptors
• Drift — review mock drift records where stubbed responses diverge from the real upstream
• Verify — assert that MockServer received the requests you expected (a single request a given number of times, or an ordered sequence) without writing test code
• Contract — run an OpenAPI spec's operations against a live service and validate every response against the contract, or validate traffic already recorded against the spec with no live service involved
• SLO — assert service-level objectives (latency percentiles and error rate) against recorded traffic without writing test code
• Cluster — view the state-backend cluster this node participates in: node id, coordinator, and member roles
• Metrics — JVM, request-latency, chaos, expectations-by-type, and MCP-tool-call charts (shown when metrics are enabled)

The dashboard connects to MockServer via WebSocket and updates in real time — any changes to expectations, new requests, or log events appear automatically without refreshing the page.

The UI is available for all versions of MockServer except the deployable WAR.

Launch UI

Browser

Open the dashboard in any browser:

For example, if MockServer is running on localhost on port 1080:

http://localhost:1080/mockserver/dashboard

The dashboard works as-is at localhost, an IP address, a single-word name such as a Docker or Compose service name, or a name ending in .svc, .svc.cluster.local or .internal. At any other name, for example a shared environment's host name or the Kubernetes service.namespace short form, MockServer refuses its API and live log calls with 403 (this protects against DNS rebinding) unless you list the dashboard's address in controlPlaneCorsAllowOrigin or add the name's private suffix to controlPlaneTrustedHostSuffixes. See which web pages can use MockServer's own API.

MockServerClient or ClientAndServer

The UI can be opened programmatically using the openUI() method:

The openUI() method pauses for 1 second after launching the browser to allow the UI to start collecting logs. This ensures logs are visible even if MockServer is shutdown quickly by a test shutdown function (After, AfterClass, AfterAll, etc.). The pause period can be configured using openUI(TimeUnit timeUnit, long pause).

To simplify debugging when multiple MockServer instances are created, if the logLevel is set to DEBUG and the launchUIForLogLevelDebug configuration property is enabled (default: false), the ClientAndServer constructor will automatically launch the UI.

Real-Time Updates

The dashboard connects to MockServer via WebSocket and receives updates automatically. The connection status is shown in the title bar as a coloured chip:

• Connected — actively receiving updates
• Connecting — attempting to establish a connection
• Disconnected — the connection is down; the dashboard retries automatically, waiting a little longer each time (3 seconds, then 6, 9 and 12, then every 15 seconds)

If the connection drops, a message naming the host and port appears after the second failed retry, so a dashboard pointed at the wrong server is easy to spot. Once the connection has been down for 8 seconds a Connection lost banner also appears; it stays up through the retries until the connection comes back, and if you close it, it stays closed until the next time the connection is lost. Data shown while disconnected may be out of date.

Updates are throttled to at most one per second to prevent UI flooding during high-traffic scenarios. If the browser has not yet received the previous update (for example over a slow network, or when captured requests have large bodies), MockServer waits for it to catch up and then sends the latest state, rather than queuing updates the browser cannot keep up with.

Large bodies are shortened in the dashboard. A request or response body longer than 64 KiB is shown cut to its first 64 KiB, with a note saying how long it is in full and a Load Full Body button that fetches the whole body from MockServer when you need it. Every action that sends, matches, copies, compares or builds a mock from a request (Replay, Repeat, Clear, Copy as curl, Capture as Mock, Create Mock, Compare, Add to Diff Pool, Why Didn't This Match? and Generate Stub) loads the full body first, so none acts on a shortened one; if the request has already been cleared from the log it does nothing and says so. The LLM views (Traffic, Trace, LLM Optimise and MCP Health) load the full bodies of LLM and MCP requests by themselves (up to 4 MiB each; load a larger one with its button), so a long conversation is still recognised and counted. Search covers only the part of a body that is shown: while a search is active the Traffic view says how many requests have a longer body, and Search Full Bodies loads them so the search covers them too. Active Expectations shortens any value in an expectation longer than 64K characters (a body, an LLM completion, a template) to its first 64K characters, says so when you expand the expectation, and does not offer to copy a shortened one. Edit, Duplicate and Test, picking an expectation in the Mocks composer, and editing an LLM conversation load the whole expectation from MockServer first, so an edit never saves a shortened value (if the expectation has been removed meanwhile, nothing is done and the dashboard says so). MockServer itself always keeps and serves the full body; only the dashboard's live view is shortened. If many recent requests have large bodies, an update can reach its size limit (about 16 MB); the dashboard then shows the newest requests and says older ones are not shown. Log messages may fill only part of an update, so many log messages never hide requests: a request that matches no expectation logs a message for each expectation it was compared with, and with many expectations the Dashboard may show fewer log messages than requests, and says so. Filter the requests or clear the log to see older ones.

Common Features

These behaviours and controls are shared across the dashboard — the navigation bar, the title-bar tools, and the way items are displayed in every panel. The per-view walkthrough that follows builds on them.

Collapsible Items

All items in every panel are collapsed by default, showing a one-line summary (e.g. method and path for requests, timestamp and type for log entries). Click any row to expand it and see the full JSON details. This keeps the dashboard compact and lets you focus on the items you care about.

Search

Each panel has its own search box that filters items by matching any part of the item's content. For example, searching for POST in the Received Requests panel will show only POST requests. The search covers all fields including headers, paths, and response bodies.

Copy to Clipboard

Hover over any item to reveal a copy button. Clicking it copies the full content of that item to your clipboard as text. For grouped log entries (e.g. FORWARDED_REQUEST), the copy button copies the entire group including all child entries.

Keyboard Shortcuts

Dark and Light Mode

The dashboard defaults to dark mode. Click the sun/moon icon in the title bar to switch between dark and light themes. Your preference is saved in the browser's local storage.

Following New Entries

The live panels — Log Messages, Received Requests, Proxied Requests, and the Traffic list — show entries oldest-first, with the newest appended at the bottom, like a console in a build pipeline. Each of them has a Follow chip in its header, reading Following while it is on: the panel then stays pinned to the newest entries as they arrive. Turn it off and the view stays exactly where you left it, so you can read without the content moving. Scrolling up with the wheel or the keyboard turns Follow off for that panel, and scrolling back down to the bottom the same way turns it back on; clicking the chip works either way, and jumps you to the newest entries. The toolbar also has a master Follow new entries / Stop following new entries switch that sets every panel at once. Active Expectations is a set of registered mocks rather than a stream of events, so it keeps its own order and has no Follow chip.

Workspaces

A workspace bundles the active view and each panel's search term, so one browser tab can hold several independent investigations open at once — for example, Traffic filtered one way in one workspace and the Mocks composer open in another. Click the New Workspace icon in the title bar to create one; once a second workspace exists, a tab bar appears below the title bar to switch between them, double-click a tab to rename it, and close a tab to remove that workspace. The theme and the request filter are shared across every workspace.

Each workspace can also point at its own MockServer, so you can watch, say, a local server in one tab and a shared test environment in another. Click the server icon on a workspace tab and enter the host, port, whether it uses https, and a base path if it sits behind a proxy. The dashboard checks the server answers before saving, and says why if it does not; you can still save a server that is not running yet. Once any workspace has its own server, every tab shows the server it talks to, and the tab bar stays visible even when only one workspace is left, so you can always see and change where it points. Everything in a workspace — the live view, and actions such as deleting an expectation or clearing logs — goes to that workspace's server only. Switching to a workspace on a different server clears what was shown and loads the other server's data. Breakpoints you set on a server stay active while any workspace still points at it, and are removed when you close or repoint the last one.

A server on a different host or port from the dashboard is reached cross-origin, so the browser applies CORS. MockServer allows this by default only when the dashboard is on localhost, 127.0.0.1 or [::1]; for a dashboard on any other host, set controlPlaneCorsAllowOrigin on the target server to the dashboard's origin (for example http://mockserver-a.internal:1080). It also fails if controlPlaneCorsAllowOrigin lists other origins but not the dashboard's, if a proxy in front of MockServer drops the CORS headers, or if the dashboard is served over https and the server is plain http.

Clear and Reset

Click the clear icon in the title bar to access three options:

• Clear Server Logs — clears the server's log, which also holds the recorded and proxied requests, so they are removed too (the same as PUT /mockserver/clear?type=log). Expectations are kept
• Clear Server Expectations — removes all active expectations while keeping logs and request history
• Reset Server (all) — clears everything: logs, expectations, received requests, and proxied requests

Menu Bar (left side)

The far left of the menu bar shows the product name and live status indicators (the navigation tabs sit to their right, and the title-bar tools to the far right):

Title Bar Tools

The title bar exposes several server tools as icon buttons. Each opens a dialog or control in the dashboard; the linked pages explain the underlying feature in full:

Tools Menu

The tools (wrench) icon in the title bar opens a menu of import, mocking, and inspection tools:

Get Started

The Get Started view is the first screen you see. It presents six action cards covering the key things MockServer does — open any one to jump straight in, or use the navigation tabs above for the full feature set:

Below the cards, a More in the tabs above list links to the remaining views — Dashboard (active mocks & live event log), Library (import / export, Postman, WSDL, HAR), Verification (assert which requests were received), Drift (spot when an upstream API changes), Async (Kafka / MQTT / AMQP broker mocking), and Metrics (Prometheus stats).

MockServer never moves you away from Get Started on its own. When the server already has mocks or recorded requests, a banner says so (for example "This server has 3 active mocks") with an Open Dashboard button. The Get Started view stays available at any time from the navigation bar.

Dashboard

The Dashboard view shows four panels in a 2×2 grid:

For LLM expectations and requests, a second row of chips shows the LLM provider, model name, turn position (e.g. "turn 2 of 3"), and isolation key. Expanding any row shows the full JSON, aligned with the expectation ID column.

Request Filter

The Request Filter panel (toggled with ⌘⇧F / Ctrl+Shift+F, or by clicking the filter icon) appears on the Dashboard, Traffic, and Trace views. It filters all panels by request properties:

• Method — HTTP method (GET, POST, PUT, DELETE, etc.)
• Path — request path (supports exact match)
• Headers — filter by request headers (name/value pairs)
• Query String Parameters — filter by query parameters (name/value pairs)
• Cookies — filter by cookies (name/value pairs)

The filter is sent to the MockServer backend via WebSocket, so filtering happens server-side and only matching data is sent to the browser.

Log Messages

The Log Messages panel lists all log events recorded by MockServer. Events are displayed oldest first, with the most recent appended at the bottom, and are color-coded by type:

Related log events (e.g. request received → expectation matched → response sent) are grouped together by correlation ID and displayed with an orange left border. Click the expand button to see all related events within a group. Click the correlation ID chip to copy it, or click Explain to see which expectation would serve that request now, why each expectation ahead of it was skipped, and which lower-priority expectations it shadows (see explaining why a request matched).

The because section in EXPECTATION_NOT_MATCHED entries can be expanded to show which properties matched and which did not, making it easy to debug why a request was not matched.

MockServer keeps only a bounded number of recent log events in memory (controlled by maxLogEntries). Once that limit is reached the oldest events are dropped — a common, easy-to-miss cause of "verification intermittently fails" or requests seeming to vanish from the dashboard. When this happens, the Dashboard and Traffic views show a dismissible warning telling you how many events have been dropped; increase maxLogEntries (see also the performance guide) so events are retained. The warning only appears when the server is started with metrics enabled and events are actually being dropped.

When a verification fails because of this (see failVerificationOnEvictedLog), its VERIFICATION_FAILED entry in the log says which limit was reached, how many entries were lost to it since the event log was last reset, and which setting to change. This is the same information the failed verify call returns, and it is shown whether or not metrics are enabled.

Active Expectations

The Active Expectations panel shows all currently active expectations in the order they are applied, taking into account priority, timeToLive, and times. Each expectation is collapsed by default showing its ID, method, and path. Click to expand and see the full expectation definition including request matchers, actions, and timing constraints. Hover a row to edit, duplicate, or delete a single expectation.

To remove several at once, click Select in the panel header to turn on multi-select: tick the checkbox on each expectation you want (or use the header checkbox to select all), then click Delete selected and confirm. Recorded requests and logs are kept.

Click Lint in the panel header to find expectations that can never match, or will not match the way they read: one hidden behind an earlier expectation that always matches first, a path without its leading /, times of 0, and so on. Each finding shows its severity, rule and message; for a hidden expectation it also names the one that wins, and clicking any expectation id opens it in the Mocks composer so you can fix it. When you create an expectation in the Mocks composer, import Expectation JSON, register a generated stub, capture a request as a mock or apply a suggested fix, and the server finds a problem, a Lint Warnings badge appears that opens the same list (see linting expectations).

Received Requests

The Received Requests panel shows all HTTP requests received by MockServer, oldest first with the newest appended at the bottom. This includes requests that matched a mock expectation, requests that were proxied, and requests that received a default 404 response. Each item shows the method and path. Click to expand and see the full request details including headers, query parameters, and body, together with the response that MockServer returned.

DNS queries and binary messages that MockServer receives are listed here too. A DNS query shows DNS with the name and record type it asked for, for example DNS api.example.com A. A binary message shows BINARY with its length and its first 16 bytes in hex; with redactSecretsInLog enabled it shows bytes redacted instead, and its bytes are masked. Like a large HTTP body, a large binary message is shortened in the panel and can be loaded in full. These requests appear only in this panel: the Traffic view and the Test Template dialog list HTTP requests only.

Proxied Requests

The Proxied Requests panel shows requests that were forwarded to a destination server along with the actual response received. Each item shows the method and path. Click to expand and see:

• The full request sent to the destination server
• The actual response received from the destination server (status code, headers, and body)

This is useful when using MockServer as a proxy to debug connectivity issues, inspect request/response pairs, or create expectations based on real traffic.

Traffic

The Traffic view is purpose-built for inspecting captured request/response pairs. It covers all captured traffic in one place — both requests that matched a mock expectation and requests that were forwarded to a real upstream. Switch to it using the Traffic button in the navigation bar.

The Traffic view has two areas:

• Master list (left) — one row per request, showing the provider kind (Anthropic, OpenAI, Gemini, Ollama, MCP, HTTP), HTTP method and path, status code, and — for LLM calls — the model name and token counts.
• Detail pane (right) — shown when you click a row in the master list, or press Enter or Space on it. Tab moves into the list and the up and down arrow keys move between rows.

A request that matches no expectation is shown with MockServer's 404, an unmatched badge, and the Why Didn't This Match? and Generate Stub buttons. MockServer records that 404 only at log level INFO or lower, so at WARN, ERROR or OFF these requests show no status and none of those, and the Traffic view says so. Set the log level to INFO (for example in the Configuration dialog) to get them back.

The master list header also has a Compare toggle (pick exactly two requests to diff them field-by-field) and a Select toggle for bulk actions: tick any number of rows (or use the header checkbox to select all), then click Clear and confirm to remove those captured requests from the log. Because requests are cleared by matching their shape, identical requests captured alongside a selection may also be removed. Select and Compare are separate modes — turning one on turns the other off.

Promote to Mocks

A Promote to Mocks button in the Traffic header (enabled once at least one request has been proxied) turns recorded traffic into active mock expectations in one step: MockServer consolidates duplicate exchanges into reusable mocks, generalises volatile values, redacts sensitive headers and values (Authorization, API keys, cookies, and similar) so captured credentials are never baked into a mock, and activates the result. An optional method/path filter in the dialog lets you promote only a subset of what has been recorded; leaving both blank promotes everything. This is the quickest way to go from "recorded against the real service" to "serving the same responses as mocks" without hand-writing any expectations.

LLM Usage Strip

For any LLM request, a thin strip appears above the detail tabs showing the provider, model name, token counts (input and output), estimated cost, and stop reason. This lets you see the key usage metrics at a glance without switching tabs.

Detail Tabs by Traffic Kind

Conversation View

The Conversation tab renders LLM exchanges as a chat transcript. It is available for all five supported LLM providers: Anthropic, OpenAI, OpenAI Responses API, Gemini, and Ollama. User messages are left-aligned and assistant messages are right-aligned, styled as WhatsApp-style chat bubbles. System prompts appear as a distinct banner above the conversation. Tool calls and tool results each appear as their own labelled bubbles.

SSE Timeline

The SSE Timeline tab shows each Server-Sent Event from a streamed LLM response as a separate row. This makes it easy to spot latency spikes within a single response. The final reassembled message is also shown. If the captured body was truncated (because it exceeded maxStreamingCaptureBytes), a banner indicates this.

Capture as Mock

A Capture as mock button appears in the top-right of the detail pane for any LLM-kind request. Clicking it creates a mock expectation directly from the captured traffic — the next matching request will receive the same response without hitting the real API.

Compare Two Requests

The master list toolbar has a Compare toggle for diffing two captured requests field-by-field — useful for spotting why two seemingly similar requests behaved differently (a missing header, a changed query parameter, a different body field).

1. Click Compare to enter compare mode. Rows in the master list become selectable.
2. Pick exactly two requests. The button next to the toggle shows the running count (Diff (1/2), Diff (2/2)) and only enables once two are selected.
3. Click Diff to open the Diff Two Requests dialog. The two selected requests are pre-filled as JSON into the Expected request and Actual request boxes — you can edit either, or hand-author one. Click the dialog's Compare button to run the comparison.
4. The result is shown as a table of the fields that differ — Field, Expected, Actual, and a Type chip (ADDED, REMOVED, or CHANGED) — with a count of the differences. When the two requests match, it reports that they are identical.

Click Compare again to leave compare mode and clear the selection. The diff is computed server-side via the PUT /mockserver/diff endpoint, which takes an expected and an actual request and returns the field-level differences, so the dashboard shows exactly what the server sees.

Request Replay

A Replay button appears in the top-right of the detail pane for any captured request. It re-issues that request to its original target and displays the upstream response — useful for checking whether an upstream has changed, or for comparing what a real upstream returns against what a mock returns.

1. Select any captured request in the master list to open its detail pane.
2. Click the Replay button in the detail pane header. A dialog opens showing the request that will be replayed.
3. Click Replay in the dialog. MockServer sends the captured httpRequest to its original target via PUT /mockserver/replay and displays the upstream response as JSON.
4. Click Replay Again to re-issue the same request without closing the dialog.

SSRF protection: replay uses the same host-allowlist policy as forward expectations. Requests targeting loopback addresses, private RFC-1918 ranges, or hosts not on the configured allowlist are blocked by the server. If a replay is blocked, the dialog shows the SSRF-policy error returned by the server.

Size limit: response bodies exceeding 10 MB are not returned via the control plane. If the upstream response is larger, the server returns an error message explaining the cap; the upstream call was still made.

Replay is distinct from cassette replay (which loads saved expectations from a file) — it re-issues a single captured request to a live upstream and shows the live response.

Repeat Request

A Repeat… button sits next to Replay in the detail pane header for any captured request. Where Replay sends the request once, Repeat re-sends it a chosen number of times — useful for generating load against a single endpoint, or for checking that an upstream behaves consistently across many calls.

1. Select a captured request and click Repeat… to open the Repeat Request dialog. A warning names the method and path that will be re-sent, and calls out that a non-GET method may mutate state or incur costs (for example, LLM API charges) that a high iteration count would amplify.
2. Set Iterations (1 to 1000), Concurrency (1 to 20 requests in flight at once), and Delay (ms) between requests.
3. Click Start. A progress bar tracks requests sent, succeeded, and failed; click Cancel to stop early. Each iteration re-issues the request through PUT /mockserver/replay, so the fan-out happens from the browser while MockServer itself sends one request per iteration.
4. When it finishes, a summary reports how many succeeded and failed, with a View Them button that jumps back to Traffic filtered to the request's path. New traffic entries appear in the list as they are sent.

Trace

The Trace view groups related requests together — including LLM agent runs — so you can follow a multi-step flow end to end. It organises captured LLM traffic into swim-lanes grouped by isolated conversation session, and has two tabs: Traces and Compare.

On the Traces tab, each swim-lane is labelled <scenarioName> / <isolation-value> (for example, weather-agent / agent-A) and shows chips for each captured turn. Click a chip to open the conversation view for that turn directly below the swim-lane.

The scenario name is the conversation name you supplied (or that MockServer auto-generated) when you registered the LLM conversation mock. The isolation value is the specific header, query parameter, or cookie value that identifies this session within the scenario — for example, the value of the x-session-id request header.

An Unscoped requests strip at the bottom holds requests that did not match any isolated scenario — for example, requests made outside a scripted conversation or without an isolation header.

Trace is most useful when you have set up LLM conversation mocks with per-session isolation. Each unique session identifier (header, query parameter, or cookie value) gets its own swim-lane, so you can trace multiple concurrent test sessions independently.

Compare

The Trace view's second tab, Compare, compares two captured conversation runs side-by-side. Pick Run A and Run B from the available sessions and the view shows a structural trajectory diff: the tool-call chain for each run and a per-turn token usage table. This makes it easy to spot regressions in agent behaviour between test runs.

Breakpoints

The Breakpoints view is the dashboard control panel for Interactive Breakpoints — the ability to pause live HTTP exchanges and streaming frames mid-flight, inspect them, and decide how to continue. Breakpoints are activated by registering a request matcher via PUT /mockserver/breakpoint/matcher; the view shows no active matchers when none are registered.

The view has three tabs:

• Matchers — register a new breakpoint matcher (method, path regex, headers, query parameters, cookies, and an optional response status range such as 500 to 599) and choose which phases to pause on (Request, Response, Response stream frames, Inbound stream frames). The status range is checked at the Response phase only. A scope box above the form takes the Traffic search operators (method:, path:, host: and status:, for example status:>=500) and fills the form from them. A matcher with none of the request fields set would pause every request, so the dashboard asks you to confirm it first, unless a status range limits it to the Response phase. A table of registered matchers shows each matcher's id, pattern, any status range, active phases, owner, and a remove action.
• Live Exchanges — request and response exchanges currently paused at a breakpoint, awaiting a decision.
• Live Streams — paused streaming frames (SSE, gRPC, WebSocket, GraphQL subscription), one row per frame.

The Live Exchanges and Live Streams tabs list all currently paused exchanges and stream frames. Live Streams shows one row per paused frame with its direction (INBOUND/OUTBOUND), stream id, sequence number within the stream, the request method and path, and a preview of the frame body; frames from the same stream share a stream id. Actions available on each paused item: Continue (release unchanged), Modify (replace the body), Drop (discard), Inject (continue and add a new frame after it), or Close (terminate the stream). Request and response breakpoints show the full request or response for inspection and allow modification or abort before the exchange is forwarded.

If you do not act on a paused item within the breakpoint timeout (breakpointTimeoutMillis, 30 seconds by default), MockServer continues it unchanged; the dashboard then removes it from the list and shows a notice saying so. If you had already clicked an action just as the timeout passed, the notice tells you that your decision was not applied.

See Interactive Breakpoints for the full matcher API reference, callback WebSocket protocol, and configuration details.

Audit

The Audit view shows the control-plane audit trail — a newest-first list of control-plane mutations — who changed what (register or clear an expectation, reset, a configuration change, and so on), with the method, path, operation, source address, principal, how the principal was established, and whether it was authorized. This is a separate, additional trail from the request/response log shown on the Dashboard and Traffic views: the audit trail never contains request/response traffic, and it never stores request headers or bodies.

Recording is off by default. A status chip at the top of the view reads Audit Trail: On or Audit Trail: Off:

• When off, click Enable Audit Trail to turn it on. Only changes made after enabling are recorded — nothing retroactive.
• When on, a switch turns recording back off (this only stops recording; it is not destructive).
• An Also record reads checkbox additionally records reads of control-plane endpoints — by default only mutations are recorded, though a forbidden read is always recorded regardless of this setting.

The view does not poll; click Refresh to pull the latest entries. The same controls are available as configuration properties — controlPlaneAuditEnabled and controlPlaneAuditReads — for enabling the trail at startup instead of from the dashboard.

Mocks

The Mocks view lets you create or edit mock expectations without writing any code. Open it using the Mocks button in the navigation bar. It has two tabs: Compose, for building mocks, and Scenarios, for the state machines your mocks step through.

A Quick mock / Advanced switch at the top picks how much of the form you see. Quick mock covers the most common case — a method and path, and a response status code, content type and body — on one short form. Advanced shows every option described below. Switching keeps what you have typed. The status code must be a whole number from 100 to 999; until it is, the register button stays disabled and says why.

Code editors in the form (such as the response body) behave like any other field for the keyboard: Tab and Shift+Tab move to the next or previous field, and screen readers announce the editor by the field's name. To type a Tab character inside an editor instead, press Ctrl+M (Ctrl+Shift+M on macOS) while it has focus; press it again to make Tab move between fields once more.

At the top, choose an Expectation kind:

• HTTP — any HTTP mock or proxy rule (described below as the standard HTTP expectation)
• LLM Conversation — multi-turn scripted LLM conversations
• gRPC — gRPC services, transcoded to HTTP POST /package.Service/Method
• DNS — DNS resolution responses, matched by name and record type
• MCP — HTTP response expectations exposed to AI agents as Model Context Protocol tools
• Import — bulk-load expectations from an external source (see Import below)

Standard HTTP Expectation

In Advanced mode, the Existing HTTP mocks list shows the active expectations of the selected kind. Click one to prefill every field and edit it in place; while you edit, a before-and-after view shows exactly what will change. New / clear drops the selection and empties the form. A search box filters the list by path or id. The dashboard keeps a limited number of expectations live (the same window as the Dashboard's Active Expectations); when the server holds more, the list says how many are shown out of the total, and searching looks through every expectation on the server so you can still find and edit any of them.

Saving an edited mock changes only the fields you edited. Fields this form cannot edit (for example a per-message delay, or primary) are listed under Other fields below the action and are saved as shown; use a field's remove button to drop it. The code tabs include these fields, so the code you copy registers the same mock. Where a language's client library has no place for a field, the snippet names that field in a NOTE comment instead of leaving it out silently; the JSON and curl tabs always carry every field.

WebSocket messages and responses, WebSocket frame matchers, SSE events and gRPC stream messages are edited one per row, with buttons to move a row up or down or remove it. A row keeps its own other fields (such as a per-message delay) when you edit, move or remove other rows; a row you add starts with none. A message can span several lines; to add several messages at once, paste them one per line into an empty row (a pasted JSON value, such as pretty-printed JSON, stays one message), or use a row's Split button.

The form is split into four steps:

1. Match a request — Expectation ID (optional — used to update an existing expectation), Method, Path, Headers, Query string parameters, Cookies, Path parameters, Body matcher, "Body is binary (base64)" toggle, HTTPS-only toggle, Priority (higher wins when multiple expectations match), Times (how many times the expectation can be used; 0 means unlimited). Prefix any string field or any entry line with ! to negate it — for example, !GET matches any method except GET.
2. Respond with — choose one of twelve response actions: Static HTTP response, Forward to upstream, Forward with override, Forward with fallback, Class callback, Response template, Error / fault injection, WebSocket response, SSE response, Binary response, Forward template, or Forward class callback.
3. Action details — fields specific to the chosen action (status code and body for a static response; host and port for forwarding; template text for a template response; etc.).
4. Review & register — a read-only preview of the generated expectation as code, in nine tabs: Java, Node.js, Python, Go, C#, Ruby, Rust, JSON and curl. Test Matcher checks whether a sample request would match, and Try It sends a real request to the server. Click Register expectation to activate it on the server. If the Expectation ID field is filled, this updates the existing expectation in place.

LLM Conversation

The Existing LLM scenarios list shows active scripted LLM conversation scenarios by name (for example, weather-agent (2 turns)). Clicking one prefills the form with the existing scenario's configuration.

The form is split into three steps:

1. Conversation basics — provider (Anthropic, OpenAI, Gemini, etc.), path to match (e.g. /v1/messages), optional model name, and optional per-session isolation (header, query parameter, or cookie name whose value is used to keep concurrent sessions independent).
2. Turns — an ordered list of conversation turns. Each turn has an optional match predicate (turn index, message content substring, message role, or tool result presence) and an optional response (text, tool calls, stop reason, token usage, streaming flag).
3. Review & register — preview in Java, JSON, or MCP format, then click Register on server (or Update N expectations when editing). When editing an existing scenario, the expectation IDs are reused so the update happens in place.

See LLM Conversation Mocking for full details on conversation predicates and isolation options.

gRPC

The gRPC kind mocks a gRPC service. MockServer transcodes gRPC calls to HTTP, so the request matcher is pre-shaped with the POST method and a /package.Service/Method path pattern; otherwise it uses the same matcher fields as a Standard HTTP expectation. The response action is a gRPC stream response (for streaming RPCs) or a static response (for unary RPCs). See gRPC Support for details.

DNS

The DNS kind mocks DNS resolution. Instead of the HTTP matcher, the form shows a DNS matcher: the DNS name (required), the record type (A, AAAA, CNAME, MX, SRV, TXT, PTR), and the record class (IN, CH, HS, ANY). The response action is a DNS response with a response code (NOERROR, FORMERR, SERVFAIL, NXDOMAIN, NOTIMP, REFUSED) and one or more answer records.

MCP

The MCP kind exposes HTTP response expectations to AI agents as Model Context Protocol tools. The form is the same as a Standard HTTP expectation but limited to static-response expectations. An MCP Tools panel lists the generated tool definitions — each with its tool name, endpoint (method and path), and description — so you can see exactly which tools an agent will discover.

Snippet Palette

When Response template is selected as the response action in the Standard HTTP Expectation form, an Insert snippet button appears next to the template body field. Clicking it opens the snippet palette — a popover menu of curated template expressions organised into three categories:

The palette is engine-aware: it shows the correct syntax for whichever template engine is currently selected in the form — Velocity, Mustache, or JavaScript. Each snippet entry shows the expression syntax as a chip, a short description, and an example rendered value. Click any snippet to insert it at the cursor position in the template body field.

Test Template

The Response template and Forward template steps have a Test Template button next to Insert snippet. It renders the template you are writing against a sample request, without registering anything, using the server's template dry run. Choose the sample request from your recently received requests, or edit it as JSON (it starts as GET /), then click Run Test. The dialog shows:

• whether the template produced a valid response (or, for a forward template, a valid request), and the rendered result
• when it fails, the error message, the template line and column, a hint for common mistakes, and the failing line of your template with a marker under the column
• warnings, such as a Velocity or Mustache variable that did not resolve, each with its line (and its column, for Velocity)
• the raw rendered text, when it is not a valid response or request

A server tests at most two templates at once; if two are already running, the dialog says so and you can try again shortly. A template that runs too long is shown as Timed Out. The button needs a template typed into the form: a template loaded from a file cannot be tested here.

Import

The Mocks view has an Import radio button at the top of the form (alongside Standard HTTP expectation and LLM Conversation). Selecting it replaces the composer form with an import form that lets you bulk-load expectations from an external source without writing any code.

Five import formats are supported:

All import operations call the relevant MockServer control-plane endpoint (PUT /mockserver/expectation, PUT /mockserver/openapi, PUT /mockserver/wsdl, or PUT /mockserver/import?format=har|postman) and report how many expectations were created. Import is additive — it does not clear existing expectations. See Importing Expectations for details on each format.

Scenarios

The Scenarios view is a standalone nav tab over the same panel shown as the Scenarios tab inside the Mocks composer — use whichever is convenient, they show the same data. It makes MockServer's scenario state machines legible, not just controllable: beyond the existing current-state (refresh) / set-state / trigger controls and a Mermaid diagram of the states actually observed, a Scenario Details section lists, for every scenario, each of its states and the mocks bound to it.

Each scenario renders as an expandable card showing its states and, under every state, the bound mocks as METHOD /path, the state they match in, and the state they transition to (state → newState). Every bound mock has an Edit action that opens it in the Mocks composer with its scenario bindings intact, and a scenario-level Edit edits its one mock directly or offers a picker when several mocks share the scenario.

Chaos

The Chaos view groups service-scoped chaos into three collapsible sections — HTTP Service Chaos, gRPC Chaos (health status + fault injection), and TCP-Layer Chaos — each with its own Clear button (Clear HTTP / Clear gRPC / Clear TCP) in its header.

It lets you inject service-scoped chaos — faults that MockServer applies to every request it forwards to a given upstream host or service, rather than to a single expectation. This is useful for resilience and SRE testing, where you want all proxied traffic to a dependency to fail or slow down for a while without editing individual mocks.

Under Register chaos for a host, enter the upstream Host and any combination of the faults below, then click Register. The form exposes the full HTTP service-chaos fault set; leave a field blank to skip that fault. Each registration is sent to the server as one chaos profile via the PUT /mockserver/serviceChaos endpoint.

Error and connection faults

• Error status — an HTTP error status code (e.g. 503) returned instead of forwarding.
• Error prob (0–1) — the fraction of requests that receive the error status, so only some requests fail. Applies alongside an error status.
• Retry-After — value for the Retry-After response header sent with the injected error (meaningful with statuses such as 429 or 503).
• Drop prob (0–1) — probability that MockServer drops the connection instead of responding.
• Latency ms — milliseconds of delay added before each matched response.
• Seed — fixes the random draw used by the probabilistic faults so a fractional probability is reproducible across runs.

Response-body corruption

• Truncate body (0–1) — keep only this leading fraction of the response body bytes, simulating a cut-off response.
• Malformed body — append a broken-JSON fragment to corrupt the body, for testing client-side parsing resilience.
• Slow chunk bytes + Slow chunk delay ms — dribble the response body in chunks of the given size with the given delay between chunks, for testing read timeouts on a trickling response.

Quota / rate limit

A fixed-window rate limit: once Quota limit requests have been seen within Quota window ms, further requests are rejected. Expectations and registrations that share a Quota name share one counter.

• Quota name — the shared counter key.
• Quota limit — maximum requests allowed per window.
• Quota window ms — window length in milliseconds.
• Quota error status — status returned when the quota is exceeded (default 429).

Count and time windows

• Succeed first — the first N matching requests are not faulted (the service appears healthy at first).
• Fail count — after the "succeed first" requests, the next M requests are eligible for faults, then the service recovers.
• Outage after ms / Outage duration ms — a self-healing time window measured from the first match: chaos starts after "outage after" milliseconds and (when a duration is set) stops after "outage duration" milliseconds.
• Degradation ramp ms — ramp the error and drop probabilities linearly from 0 up to their configured values over this many milliseconds, so a dependency appears to deteriorate gradually rather than failing all at once.

GraphQL error envelope

Enable GraphQL errors to rewrite the response as a GraphQL error envelope (HTTP 200 with a {"data": null, "errors": [...]} body) instead of an HTTP error status — the way a GraphQL API typically signals failure. Optionally set an Error message and an Error code (placed under errors[0].extensions.code).

TTL

• TTL ms — how long the chaos stays active, in milliseconds. When the TTL elapses MockServer automatically reverts the fault (a dead-man's switch), so a forgotten chaos run cannot break later tests.

The Active registrations panel lists each host with chaos in force and its remaining auto-revert countdown (or shows No service-scoped chaos registered when none is set). Each registration can be edited in place (Apply replaces the whole profile, so clearing a field removes that fault, and a time-to-live keeps counting down) or removed with its remove icon (trash), or use the section's Clear HTTP / Clear gRPC / Clear TCP button to remove everything in that section at once. Injected faults are also counted in the Metrics view under HTTP Chaos Faults.

To drive load alongside chaos — inject a fault and simultaneously apply load to verify resilience — see the Performance view.

Chaos Experiments

Below the chaos sections, the Experiments panel defines a multi-stage chaos experiment: an ordered list of stages that progress automatically, each applying a chaos profile to an upstream host for a fixed duration — for example, 30 seconds of added latency, then 30 seconds of error responses, with no manual intervention between stages.

• Give the experiment a name, optionally turn on Loop to repeat the stage sequence indefinitely, then add one or more stages — each with a Duration ms, a Host, and the fault fields (error status/probability, latency, drop probability) to apply to that host for the stage.
• Start Experiment begins the run; a live status shows the experiment name, current stage, a progress bar for the active stage, and the total elapsed time. Stop ends it early.
• Save as Profile stores the experiment definition (name, loop setting and every stage) under the experiment's name, for one-click re-use later; SLO criteria can't be set in the dashboard, so add them through the REST API if you want an experiment to stop on an SLO breach; the saved-profiles list lets you click a chip to immediately start that saved experiment, or its delete icon to remove the saved profile.
• History (expand to load) lists past experiment runs — name, outcome, and when each one ended — up to the last 50.
• If the experiment carries SLO criteria, a terminal verdict (pass/fail per objective) is shown once the run ends; a breach detected mid-run stops the experiment immediately with status halted_by_slo_breach, attaching a FAIL verdict. This is a separate safety mechanism from the chaos auto-halt circuit-breaker (status halted_by_auto_halt), which independently stops any chaos experiment or service-scoped chaos once too many destructive faults occur in a window, regardless of SLO criteria.

Preemption Simulation

The Preemption Simulation panel simulates a Kubernetes node drain, a Spot-instance reclamation, or a pre-SIGTERM sequence: MockServer cordons itself — turning away new data-plane requests while letting requests already in flight finish — without ever actually stopping the server. This is a simulation only; it never stops the JVM or event loops, and the control plane (/mockserver/...) stays reachable throughout so you can always observe and uncordon.

• A mode selector offers both (reject new requests with 503 and signal HTTP/2 clients to stop opening streams via GOAWAY), reject503 (503 only), or goaway (GOAWAY only, no 503).
• Drain ms — how long in-flight requests are given to finish before the cordon reports itself drained.
• TTL ms — an optional dead-man's switch that auto-uncordons after this many milliseconds, so a forgotten simulation cannot block traffic indefinitely.
• Start Preemption begins the cordon; the current-state panel shows the live state (inactive / draining / drained), the in-flight request count, and the remaining drain time. Clear Preemption uncordons immediately.

Performance

The Performance view lets you create, run, and monitor load scenarios directly from the dashboard — server-side load generation that drives traffic at a target and charts live throughput and latency. Switch to it using the Performance button in the navigation bar. Load generation must be enabled first (configuration property loadGenerationEnabled / MOCKSERVER_LOAD_GENERATION_ENABLED); until then the panel shows the configuration flag needed to unlock it.

The view has three areas:

• Stage builder — add an ordered list of stages to the load profile. For each stage choose:
  • VU (closed model) — hold a fixed number of concurrent virtual users, or ramp from startVus to endVus
  • RATE (open model) — hold or ramp an arrival rate in iterations per second, with an optional maxVus cap on the auto-scaling VU pool
  • PAUSE — drive no load for the duration (lets the target recover between stages)
  Ramp stages accept a curve of LINEAR, QUADRATIC, or EXPONENTIAL, and each stage's duration is set in milliseconds. A scenario also has a Template type (the engine used to render each step's path and body, e.g. Velocity), optional Labels, an optional Max requests cap, and one or more Steps — the request each virtual user issues per iteration (method, path, target host/port and scheme, an optional templated body and headers, and a think-time delay between steps).
• Live status — once a scenario starts, the panel shows the running scenario name and run id, the current stage index, stage type (VU / RATE / PAUSE), current target (active VUs or arrival rate), elapsed time, requests sent, success / error rate, and latency percentiles (p50 / p95 / p99). The status polls GET /mockserver/loadScenario and refreshes automatically.
• Metrics graph — a toggleable combined chart showing throughput (requests/second) and p95 latency over the lifetime of the run, drawn from the mock_server_load_* Prometheus family. The graph requires metricsEnabled=true.

Two buttons sit below the form: Load registers the scenario without running it (staged ready to trigger), and Load & Run registers it and starts it immediately. While a scenario runs, its card on Run & Monitor has Edit running (load it back into the form to tweak and restart) and Stop. When nothing is running any more, Run & Monitor shows a summary of the most recent run: key metrics, threshold results, and buttons that download the run report as JSON or JUnit XML. Clear all and a scenario's delete button ask for confirmation first, because both also stop a running scenario. The same lifecycle is available over the control plane: PUT /mockserver/loadScenario registers a scenario, PUT /mockserver/loadScenario/start triggers it, PUT /mockserver/loadScenario/stop stops it, and DELETE /mockserver/loadScenario stops everything and clears the list. Enable sloTrackingEnabled as well to record latency / error SLO samples for the run. See Performance Testing / Load Injection for the full REST API reference, safety caps, SLO integration, and Prometheus metric catalogue.

LLM Optimise

The LLM Optimise view analyses captured LLM traffic and produces an optimisation brief — concrete, ranked opportunities to cut inference cost and latency and tighten prompt hygiene. Switch to it using the LLM Optimise button in the navigation bar. It is read-only analysis over traffic MockServer has already proxied or recorded; it does not change any mocks.

A header strip summarises the analysed traffic — estimated total cost, input and output token totals, call count, and latency — with a Session selector to scope the analysis (for example, all captured LLM traffic). Below it, Detected Opportunities lists each finding as a card with a severity, an explanation, and a concrete Recommendation. Signals include repeated identical system prompts (candidates for prompt caching), large static context resent every turn, tool lookups that could be made deterministic, oversized tool results, duplicate consecutive calls, and output-token bloat.

Use Copy optimisation brief to copy a Markdown summary for an LLM or teammate to act on, or Download bundle for the full JSON. The same report is available over the control plane and as an MCP tool. See LLM Optimisation for the full signal set.

MCP Server Health

The MCP Server Health view shows, per MCP server, how the MCP servers your proxied tools call are actually performing — so when a coding-assistant CLI feels slow, you can see whether the MCP server is the real bottleneck rather than MockServer itself. Switch to it using the MCP Health button (in the AI group) in the navigation bar. It is read-only analysis derived from the MCP (JSON-RPC over HTTP) traffic MockServer has already proxied or recorded; it does not change any mocks.

Each row is one MCP server (grouped by host), shown worst-first, with:

• Errors — the error rate (a JSON-RPC error response or a non-2xx status) as a percentage of the calls measured.
• Median, p95, and Max latency — how long that server took to respond.
• Slowest method — the tool method behind the slowest call.

There is no call count: the view measures only the most recent captured traffic, so a count would stop at that limit however much traffic really ran. The error rate and latencies are proportions and percentiles of that sample, which stay meaningful.

A server is flagged slow when its p95 or max latency is at or over the slow threshold, and errors when any call failed, so the servers most likely to be hurting your assistant rise to the top. When no MCP traffic has been captured yet, the view explains that proxying a tool that talks to MCP servers will populate it. See MCP Tools for MockServer's MCP support.

Async

The Async view shows the live status of the AsyncAPI broker mock — MockServer's message-broker mocking for Kafka, AMQP, MQTT, and other async transports. Switch to it using the Async button in the navigation bar. The view polls the server every few seconds and refreshes automatically; you can also refresh on demand.

At the top a status chip shows no spec loaded, spec loaded, no broker (a spec is loaded but MockServer has no publisher or subscriber attached to a broker), or broker connected. A second chip shows the spec's title and its AsyncAPI document version (for example Orders · AsyncAPI 3.0.0). The view then shows:

• Channels — each channel (topic) defined by the loaded AsyncAPI spec, whether it has a message schema, and how many example messages it carries.
• Publisher / subscriber summary — how many publishers and subscribers are active, and how many messages have been recorded.
• Recorded Messages — messages captured from broker subscriptions, showing the channel, message key, payload, schema-validity, and time. A filter box narrows the list by channel, key, or payload.

Load a spec from the AsyncAPI Broker Mock entry in the title-bar Tools menu (or via the PUT /mockserver/asyncapi endpoint). To see recorded messages, enable consumers in your broker configuration and publish messages to the channels. If the optional AsyncAPI module is not on the server's classpath, the view shows an unavailable notice instead.

gRPC

The gRPC view lists the gRPC services MockServer can mock and inspect, loaded from compiled protobuf descriptors. Switch to it using the gRPC button in the navigation bar. The view polls the server and refreshes automatically.

For each loaded service it shows every method with its input → output message types and its streaming Kind (unary, server stream, client stream, or bidirectional stream), plus the service's health-check serving status (for example, SERVING). Load descriptors by uploading a FileDescriptorSet in the Library view's gRPC Descriptors sub-tab, by calling PUT /mockserver/grpc/descriptors, or by configuring a descriptor / proto directory at startup. See gRPC Mocking for how to mock gRPC methods.

Library

The Library view consolidates importing, exporting, and fixture file management. It has five sub-tabs: Import, Export, Cassettes, WASM Modules, and gRPC Descriptors.

Import

The Import sub-tab bulk-loads expectations from an external source — Expectation JSON, OpenAPI, WSDL / SOAP, HAR, or a Postman collection. It is the same import form offered as the Import kind in the Mocks composer; see Import for the full list of formats and what MockServer creates from each.

Export

The Export sub-tab lets you download captured content from the running MockServer instance. Pick what to export and the format, then click Download. The What to export options cover four scopes — recorded requests, active expectations, recorded expectations, and server logs — and the format dropdown filters itself to the formats valid for the scope you pick. A few formats apply to only one scope:

OpenAPI, Postman, and Bruno exports are best-effort: positive-string matchers round-trip cleanly, but MockServer's NottableString negation, regex bodies, and dynamic actions (forward / template / callback / error / LLM) appear as placeholder text since those formats describe client requests + example responses rather than full mock-server expectation graphs. Use MockServer JSON when you need a lossless round-trip.

Cassettes

The Cassettes sub-tab manages JSON cassette files — snapshots of the current MockServer state. A recorded cassette contains all captured LLM/MCP traffic as mock expectations, with sensitive headers (API keys, auth tokens, cookies) automatically redacted. The file can be committed to version control and loaded in tests for deterministic, offline replay. It has four inner tabs:

• List — a table of tracked cassettes showing filename, path, expectation count, last used, and origin (recorded or loaded), each with a delete action.
• Record — record a new cassette file, with optional request-path and host filters, via the record_llm_fixtures MCP tool.
• Load — load expectations back from a server-side JSON file via the load_expectations_from_file MCP tool.
• Export — download the cassette metadata as JSON.

Under the hood, the List tab reads from (and Record/Load register into) an in-memory cassette registry — tracking metadata about cassette files, not their contents — via a small REST API, which you can also call directly:

• GET /mockserver/cassettes — lists every tracked cassette as {"cassettes":[{"path","filename","expectationCount","origin","lastUsed"},...]}.
• PUT /mockserver/cassettes — registers (or updates) a cassette entry from a JSON body {"path", "filename"?, "expectationCount"?, "origin"?} (path is required); responds 201 Created with the stored entry.
• DELETE /mockserver/cassettes — removes the tracked entry for a cassette, identified by path as either a query parameter (?path=...) or a JSON body field; responds 200 OK with {"removed": true|false}.

curl -sf http://mockserver:1080/mockserver/cassettes

curl -sf -X PUT http://mockserver:1080/mockserver/cassettes \
  -H 'Content-Type: application/json' \
  -d '{"path": "fixtures/openai.json", "expectationCount": 12, "origin": "recorded"}'

curl -sf -X DELETE "http://mockserver:1080/mockserver/cassettes?path=fixtures/openai.json"

Registering a tracked entry does not, by itself, write or load the underlying file — that is what the record_llm_fixtures and load_expectations_from_file MCP tools (and the UI's Record/Load tabs) do; the registry is metadata the UI's List tab reads.

WASM Modules

The WASM Modules sub-tab uploads and manages WASM custom-rule modules. Give the module a name, choose a .wasm file, and click Upload; a table lists the uploaded modules, each with a delete action. Uploaded modules become available as the WASM module body-matcher type in the Mocks composer. WASM rules are off by default; on a server where they are off, the tab explains how to turn them on (wasmEnabled=true) instead of listing modules, and checks again when you press Refresh.

gRPC Descriptors

The gRPC Descriptors sub-tab uploads a compiled protobuf FileDescriptorSet (.desc, .pb, .bin, or .protoset) so MockServer can decode gRPC traffic. After uploading, the view lists the services it contains, each method with its input → output message types, and the streaming mode (unary, client, server, or bidirectional). Use Clear all to remove the loaded descriptors.

Drift

The Drift view surfaces mock drift — where a stubbed response no longer matches what the real upstream returns. When MockServer proxies a request that also has a matching response expectation, it compares the two and records any differences. Each row shows the affected expectation, the drift type (status, schema field added/removed, schema type changed, or header added/removed/changed), the field, the expected vs actual values, a confidence score, and the time. Filter by expectation, or use Clear to reset the recorded drift. This makes it easy to spot stubs that have silently fallen out of sync with the services they stand in for.

Verify

The Verify view lets you assert — straight from the dashboard — that MockServer actually received the requests you expected, without writing any test code. It checks against the requests MockServer has already recorded: a pass means it happened, and a failure shows the closest matching requests and the actual count so you can see what went wrong. Switch to it using the Verify button in the navigation bar.

A toggle at the top picks one of two modes:

• Single request — describe one request to match (Method, Path, Headers, Query parameters, Body), then assert how many times it was received: at least, at most, exactly, or between two counts. Click Verify to run the check.
• Ordered sequence — describe two or more requests that must have been received in this order (other requests may occur in between). Add or remove steps as needed, then click Verify sequence.

Each request matcher accepts the same fields as the rest of MockServer: a method, a path, header name/value lines, query key=value lines, and a body to match as a substring or JSON: plain text matches anywhere in the body, and a JSON object or array matches any JSON body that contains those fields. Leave a field blank to match any value. The response matcher takes an exact Status code or a Status range: a class such as 4XX, or one comparison such as >= 400. The Quick scope box above each request matcher accepts the same search shorthand as the traffic views — method:, path:, host: and status: — and fills the fields for you; for example status:>=500 fills the range >= 500, and status:>=400 status:<500 fills 4XX. A header or query line without its : or = is flagged in red and blocks the check rather than being ignored, so a typo can never turn into a false pass. This is the visual equivalent of the verification API — handy for confirming, during exploratory testing, that a client made the calls you expected.

Contract

The Contract view validates a live service, or traffic already recorded through MockServer, against an OpenAPI spec — contract testing without writing any test code. Switch to it using the Contract button in the navigation bar. A toggle at the top picks one of two modes; both take the spec the same way, as a URL, file path, or inline YAML/JSON document.

Live Contract Test

Set the Target base URL of the service to exercise, and optionally narrow the run to a single operationId. Click Run contract test and MockServer calls each operation of the live service and checks the responses (status, headers, and body schema) against the contract, reporting any violations. See Using OpenAPI for how MockServer works with OpenAPI specifications.

Validate Recorded Traffic

This mode takes only the spec — no target URL, and no live service is contacted. Instead, MockServer locates every request/response pair it has already recorded (from proxying or mocking) and validates each one against the spec in place: the safer, CI-style counterpart to the live contract test, since it never issues a real request of its own. Results render as a table of method, path, matched operation, and any request/response validation errors, with pass/fail totals. If nothing has been recorded yet, the view prompts you to record or proxy some traffic first.

SLO

The SLO view lets you assert service-level objectives — latency percentiles and error rate — against the traffic MockServer has recorded, straight from the dashboard and without writing any test code. Switch to it using the SLO button (in the Verify group) in the navigation bar. Each objective compares an observed indicator against a threshold over a trailing window; every objective must hold for the check to PASS.

Give the SLO a Name, a Lookback window (seconds) and a minimum sample count, and optionally narrow it to specific Upstream hosts. Add one or more Objectives — each picks an Indicator (such as latency p95 in milliseconds, or error rate), a Comparator, and a Threshold. Click Verify SLO to evaluate every objective against recorded traffic and see which held and which breached. SLO tracking must be enabled on the server (sloTrackingEnabled=true).

Cluster

The Cluster view shows the state-backend cluster this MockServer node participates in. Switch to it using the Cluster button in the navigation bar. A standalone server reports a single local node; when MockServer is run with a shared (clustered) state backend, every member node appears here.

A status chip summarises the topology (for example, Single node with a member count). The view shows this node's Node ID and the current Coordinator, followed by a table of cluster members — each member's id, its Role (such as Coordinator), and which row is the local node. This makes it easy to confirm cluster membership and which node is coordinating shared state.

Metrics

The Metrics view charts MockServer's own runtime metrics. It is only populated when metrics collection is enabled (configuration property metricsEnabled / MOCKSERVER_METRICS_ENABLED); otherwise the view shows Metrics are disabled with the flag and environment variable needed to turn them on.

When enabled, the view shows:

• All requests received and Throughput — the total request count and a derived requests-per-second figure with a trend chart. Both count every request MockServer receives, including control-plane calls such as the dashboard's own refresh every 3 seconds, so they are not zero on an idle server. Matched, Not matched and Forwarded count only requests handled by expectations.
• Request latency — p50, p95, and p99 response-time percentiles, derived from MockServer's request-duration histogram.
• HTTP Chaos Faults — injected faults broken down by type, plus the currently active service-scoped chaos (see the Chaos view).
• Request activity and Actions executed — cumulative request and action counters over time.
• Expectations by type — the number of active expectations broken down by action type (one line per type), and MCP tool calls per tool.
• JVM heap memory and Threads & GC — heap used/committed, thread counts, garbage-collection totals, and related JVM runtime figures.