Verification and common problems - PrestaShop
The test event
On the configuration screen click Send a test event. The module sends it synchronously and shows the result together with its ID, without reloading the page; the result and its timestamp stay on the screen as a status pill. The event should appear in the panel under Errors for the project the token points at.
Verifying on a real exception
The test from the screen confirms the connection, not automatic capture. On a staging shop raise an uncaught exception - from a temporary Reporter::report() in your own module, for instance - and check that the event carries the environment, the time and the request context. Remove that code afterwards.
Common problems
The module installs but reports nothing
Clear the cache. PrestaShop keeps the list of attached hooks in the service container, so a freshly installed module can stay invisible until the container is rebuilt: php bin/console cache:clear or Advanced Parameters → Performance.
The staging shop reports into the production project
The copied shop brought its database, and the credentials with it. Override the key with the _DOCKRAY_PRIVATE_KEY_ constant in app/config/parameters.php, or set the configuration source to Constants only. The parameters file is not part of a database dump, so the next copy will not overwrite it.
I entered a key in the form but the module uses another
Usually a constant is defined in app/config/parameters.php while the configuration source is set to Auto. The status area lists which constants are active.
JavaScript errors do not arrive
The collector is off by default - enable Collect JavaScript errors in the module configuration. If nothing arrives even then, remember the front controller answers 202 even when it rejected the report: the guards are the PrestaShop token, the 16 KB limit and 20 reports per IP address per minute.
Transactions are missing although errors arrive
Request timing is controlled separately. With a transaction sample rate of 0 not a single transaction is produced - that is a setting, not a fault.
One error splits into many entries
The panel groups errors by the fingerprint sha256(project token + type + message). If the message contains an order number, a cart id or a timestamp, every occurrence is a different error as far as the panel is concerned. Move the variable part out of the message and into the context.
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.