Verification and common problems - Drupal
The test event
On the /admin/config/development/dock-ray form click Send a test event. The result and its timestamp stay in the status area, and the event itself should appear in the panel under Errors for the project the token points at.
Verifying through the log
Because the module works as a logger channel, the real test is an ordinary log entry at least as severe as the level you configured:
drush php:eval "\Drupal::logger('dock_ray_test')->error('DockRay control entry');"The entry should reach DockRay as a message. If it does not while the test event from the form works, the problem is the log level, not the connection.
Common problems
The test event works but real errors do not arrive
Check minimum_level. At 3 (Error) warnings and notices are skipped on purpose. Check as well whether the error reaches the Drupal log at all - the module reports what the logger sees, not what happens beside it.
I entered a token in the form but the module uses another
$settings['dock_ray'] is defined in settings.php while the configuration source is set to Auto - and then the key from the file wins for its field. The status area shows the value actually in effect and says where it comes from.
The token and key fields are locked
That means the value comes from settings.php. Saving the form in that state erases nothing - the Form API submits a locked field's default value along with the rest. To type them in the UI, switch the source to This form only.
Transactions are missing
Transactions are only produced when traces_sample_rate is above zero, and they close on kernel.terminate. A request that ends before that stage - cut short by exit, or served by the page cache layer - leaves no transaction behind.
JavaScript errors do not arrive
The collector is off by default and deliberately stays off admin pages. If nothing arrives after you enable it, check that /dock-ray/collector.js actually serves the file - on an install with aggressive caching or an unusual docroot that tends to be the first cause. Keep in mind the limit of 20 reports per IP address per hour, and that the receiver answers 202 even when it rejects one.
Configuration cache after editing settings.php
After editing settings.php clear the cache (drush cr). The form reads the overrides while building, so until the container is rebuilt the status area can show the previous state.
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.