Verification and common problems - WordPress
The test event
You do not have to break the site to check the connection. On Settings → DockRay click Send a test event: the plugin sends an event synchronously and shows the result together with its ID, without reloading the page. A successful test waits for a 200 {"success": true} response, and its result and timestamp stay on the screen as a status pill.
The event should show up in the panel under Errors for the project the token points at. Check three things while you are there: the environment, the time and the request context. An empty environment means the plugin received neither a value from the screen nor an environment type from WordPress.
Verifying on a real error
The test from the screen confirms the connection, but not automatic capture. To check that too, raise an uncaught exception on a staging environment - from a temporary shortcode, or from an init hook on one chosen URL - and see whether the event arrives. Remove that code once the test succeeds: every further call bumps the counter of an artificial error and eats into the monthly quota.
Common problems
Nothing arrives in the panel
Check, in order: whether a full set of credentials is present (the status pill answers that directly), whether the token and the key belong to the same project, whether the key has been revoked in the panel, and whether the host allows outbound HTTPS. The plugin does not follow redirects, so a self-hosted DockRay address has to be the final one, not one that redirects.
I entered a token on the screen but the plugin uses another
Usually that means DOCK_RAY_TOKEN or DOCK_RAY_PRIVATE_KEY is defined in wp-config.php while the configuration source is set to Auto - and then the constant wins. The status area lists which constants are active. Switch the source to This screen only if this site should report into a different project than the shared server configuration.
Events arrive, but with no stack trace or no request context
An event from a hook fired by WP-CLI or by cron has no HTTP request, so it will have no request context either - and that is correct. A missing stack on a PHP error means the event came from an error rather than an exception; there the failing place is the file and line.
Too many notices and deprecations
An install with a dozen plugins can produce hundreds a day and push the meaningful entries off the list. Narrow DOCK_RAY_ERROR_TYPES in wp-config.php to the levels your team actually reacts to.
JavaScript errors do not arrive
The collector is off by default - enable Collect JavaScript errors on the settings screen. If nothing arrives even then, remember the receiver's three guards: the nonce, the 16 KB body limit and 20 reports per IP address per minute. The receiver answers 202 even when it rejected the report, so the response status in the browser console settles nothing.
One error fills the whole list
That is usually a single exception in a loop or in cron. The panel groups errors by the fingerprint sha256(project token + type + message) and keeps one row per error per day, so such a case shows up as one row with a high counter. If it still splits into many rows, the message contains a variable part - an order id or a timestamp - and that is what has to come out of the exception text.
The panel answers 200 but there is no event
A 200 {"success": false} response means the account has used up its monthly error quota. The integration does not treat that as a failure - and rightly so. You can see the quota on the account dashboard; until the end of the month it is counted from recorded usage, so deleting errors does not reset it.
Still not working
Work through the troubleshooting checklist, and if that does not help, write to us. Include the project name, the integration version and roughly when you ran the test: it shortens the way to an answer.