Verification and common problems - PHP

A controlled event

use function Dock\Ray\captureMessage;

captureMessage('DockRay control message');

On CLI the event goes out inline (send_after_response is off there by default), which makes it the quickest way to check the connection. On the web the event leaves only after the response has been flushed - that is normal and does not mean something is broken.

Common problems

Nothing arrives in the panel

Check, in order: whether init() is called at all (the most common cause in an application without a framework), whether the token and key are set and belong to the same project, whether the key has been revoked, and whether the server allows outbound HTTPS.

CLI events arrive, web events do not

On the web, sending happens at shutdown, after the response has been flushed. If the process ends abruptly - an exit inside an error handler, a PHP-FPM crash, a killed process - the queue is never flushed. To diagnose it, switch 'send_after_response' => false temporarily: if events then arrive, the problem is how the process ends, not the connection.

The whole stack looks like vendor code

in_app_exclude is missing. Without that option the SDK does not know where your application ends and a library begins - and the failing place points at the deepest frame instead of the one that means something.

Some events disappear under load

The queue holds at most 50 events per request; beyond that new ones are dropped. If one request produces more, it almost always means an error in a loop - and the panel will show it as one row with a counter anyway. Check sample_rate as well if it has been lowered.

PHP errors are missing, only exceptions arrive

error_types follows error_reporting() by default. If the application narrows it in php.ini or in the bootstrap, DockRay receives exactly that narrowed range. Set error_types explicitly when you want something else.

Transactions are missing

In this SDK transactions have to be opened by you through HttpTransaction - there is no automatic middleware here. On top of that they are only sent when traces_sample_rate is above zero.

An event was dropped on the way

Check before_send: returning null drops the event. That is the most common cause of "some errors arrive and others do not" in an application where somebody put a filter there.

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.