Debug & Troubleshooting AI-generated
When a reaction isn't matching, or is matching the wrong thing, there are three places to look, roughly in order of how much detail they give you.
Debug tab
Every service has a Debug tab: pick an HTTP method, enter a relative URI, headers and a payload, and run it. You can also open Debug directly from a specific reaction's page, pre-populated to test that one. Click Execute and, after a moment, an execution log appears showing every reaction considered in order and why each one that didn't match was skipped - HTTP method mismatch, SOAPAction mismatch, script not matching, and so on - continuing automatically to the next reaction on each failure rather than stopping. For whichever reaction does match, it also shows the account-selection outcome, the generated payload, and any account-update values, each step timed individually so a slow expression stands out. No real client is needed to exercise any of this. Most script fields also carry their own Run button that test-executes just that field against whatever's currently loaded here.
Log table
Each environment's Log page lists calls it has actually handled (subject to that environment's Log setting - see Environments: Enabled/Only Errors/Disabled), matched or not, each with full request/response bodies and headers, which service/reaction/account matched, HTTP status, and elapsed time. The list only shows the most recent entries (bounded by the environment's Max Log Records setting) and doesn't auto-refresh - reload the page to see newly arrived calls. Click the eye icon on an entry for the full exchange; that entry's own URL is shareable and stays valid for about a day. This is the place to check when something works in Debug but not from a real client - it shows you what the real request actually looked like on the wire.
MockMotor log (file log)
The server's own file log (mockmotor.log.0, rotating through .1-.9, under the logs/ directory by default - configurable via <logsDirectory> in mockmotor.config.xml) records startup, clustering activity, exceptions (with full stack traces), console/API write operations (with the user's name; read-only GETs aren't logged, to keep the file from filling with noise), and a one-line-per-request summary for every mock call with a timing breakdown (find/exec/acc/wait milliseconds), e.g. 2017-08-13 10:50:45.888 INFO HTTP DELETE 200 2ms [MockMotor SelfTest][REST][DELETE products]. When a request takes noticeably longer than expected, this line - and, for anything slow enough, an extended per-step timestamp breakdown appended to it - is usually the fastest way to see which phase (matching, account selection, payload execution, an artificial delay) actually accounts for the time.