Use Error Monitoring to distinguish a configured destination, a successful test and a captured application error. These are different observations, so check them separately before assuming that monitoring has failed.

Check the saved state

1. Open PD Modules → Guard → Error Monitoring with Pro access active.
2. Check whether the status is Not configured, Configured — not enabled or Active — capturing errors.
3. Review Project, Forwarding, the environment and sampled percentage. Confirm that you are looking at the same project and environment in Sentry.
4. Compare Last test, Events sent and Last error sent with the time of the issue. A stored successful test is historical evidence, not proof that the current route is still available.

An active label is calculated from the enabled switch and a recognised DSN. It is not a continuous connection test. The DSN can still point to the wrong project, a changed destination or an unavailable endpoint.

Distinguish test delivery from automatic capture

Send test event sends a plain test message using the saved destination, even when automatic forwarding is off. It does not increment Events sent or exercise the real fatal-error and exception handlers. Confirm the test in Sentry rather than intentionally causing a crash to check the integration.

Automatic capture requires the forwarding switch, a DSN and active Pro access. It also applies the configured sample rate. At a reduced rate, a particular error can be omitted randomly, even if a test message arrived. Increasing the rate affects later events; it does not recover an omitted one.

Ordinary warnings and application errors that were caught and handled are outside this fatal-error/uncaught-exception route. Errors occurring before the module’s handlers load, in another runtime or on a request that does not load them may also be absent. A PHP failure caused by exhausted resources can prevent reporting itself from completing.

Inspect delivery evidence

The sender makes a short synchronous request to the configured destination and regards an HTTP success response as accepted. It does not keep a persistent queue for failed deliveries or replay old errors when the connection returns. A counter that did not increase can reflect an unobserved, sampled-out or unsuccessful event; it is not a complete list of failures.

Check Sentry’s project, environment, time filters and ingestion status, then ask the hosting administrator to review the outbound connection if needed. For a self-hosted destination, confirm that its ingestion endpoint accepts the integration’s test. Do not assume that a parseable DSN proves server compatibility or that a successful response proves the event has appeared in the selected view.

Pause forwarding without losing context

If you need to stop future automatic sends, turn off Pro: forward errors to Sentry in Settings and save. Existing project events and the module’s saved counters are not erased by this switch. The explicit test button can still send a new test while forwarding is off. Do not press it if your intention is to send nothing.

Do not paste customer error messages, stack details, DSNs or private project records into public channels. Resolve the observation or delivery gap before repeating tests.

See the PD Guard Blesta guide for related tasks, or explore PD Guard.