Use a Pro webhook to send administrator security alerts to an intended HTTPS receiver alongside email. Keep the destination private because these events can name staff, addresses and affected files.

Set the intended receiver

1. Open PD Modules → Guard → Settings with Pro active.
2. Enter Pro: alert webhook URL using the HTTPS endpoint you control or the intended Slack incoming-webhook URL.
3. For your own receiver, review Pro: webhook signing secret and arrange matching verification there.
4. Choose Save settings.
5. Open Monitoring & Alerts and choose Send test alert when you intend to transmit a real test notification.

The test button appears when a webhook URL is configured. It tests the webhook, not the email route. Check the receiving channel or endpoint after reading the result.

Interpret acceptance correctly

The sender treats an HTTP success response as acceptance and does not follow a redirect. Confirm the final intended endpoint rather than a redirecting address. Acceptance does not establish that a later automation, notification or archive at the receiver completed.

Slack receives a text payload. A custom HTTPS receiver receives a structured event. With a signing secret, custom requests include X-PDGuard-Timestamp and X-PDGuard-Signature. The receiver must verify the signature over the timestamp and original body and reject stale timestamps if it relies on replay protection. Sending a signature alone does not implement that verification for the receiver.

Check each delivery path

Email and webhook attempts have separate outcomes. A working test does not prove every future alert will arrive, and this path has no persistent delivery-retry queue. A generic monitoring or lockout result is not confirmation that both destinations received it. Keep webhook URLs, signing secrets and unredacted alert payloads out of support tickets.

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