About this plugin
Site Add-on Watchdog keeps an eye on your site’s plugins and warns you when:
- A newer release is available for an installed plugin, with an additional warning when it is two or more minor releases behind.
- The latest release’s official changelog mentions security or vulnerability fixes.
- (Optional) WPScan reports vulnerabilities affecting the installed version when you provide your own API key.
The plugin runs on a schedule you control—choose daily, weekly, a twenty-minute testing cadence, or rely on manual scans—and stores results locally. org and caches successful responses for six hours. WPScan lookups are optional.
Email risk alerts to site administrators are enabled by default; webhook channels require setup and activation.
Privacy first
- Risk processing and storage stay on your site; Watchdog does not send telemetry, site content, or user data.
- WordPress.org receives a request for each installed plugin slug when its cached directory data expires so Watchdog can retrieve public version and changelog data.
- WPScan receives one plugin-slug lookup at a time only when you add your personal API token.
- Email risk alerts to site administrators are enabled by default and can be disabled in settings. Webhook channels send detected plugin risks only after you configure and enable them.
External services
Watchdog uses the following external services under the stated conditions:
- WordPress.org Plugin API (required for directory comparisons): When cached data is unavailable, Watchdog sends each installed plugin slug separately to retrieve its public version and changelog. No site content or user data is included. See the WordPress.org service and privacy policy.
- WPScan API (optional): When you save a WPScan API token, Watchdog sends that token as authorization and submits one plugin slug at a time to retrieve vulnerability records. See WPScan, its terms, and the applicable Automattic privacy policy.
- Notification destinations: Email alerts to site administrators are enabled by default and can be disabled. Discord, Slack, Microsoft Teams, and custom webhooks are optional and send only when configured and enabled. Alerts can include plugin names, installed and available versions, risk or vulnerability details, and links back to your WordPress administration area. Those transmissions are governed by your mail provider or destination service; review the applicable policies for Discord ( privacy ), Slack ( privacy ), or Microsoft ( privacy ).
Admin tools
- Focused dashboard with risk summaries, searchable history, delivery health, and manual actions.
- Ignore list to suppress noisy plugins.
- Validated notification settings with a save-and-test action for every channel.
Notifications
- Email: send to one or more recipients separated by commas, semicolons, or spaces; site administrators are always included.
- Discord: post to a channel via webhook.
- Slack: connect via an incoming webhook to post alerts into any workspace channel.
- Microsoft Teams: send notices through Teams Workflows or an existing Incoming Webhook connector.
- Generic webhook: post JSON payload to any endpoint you control, with optional HMAC signatures. Failed deliveries are logged and highlighted on the Watchdog admin screen so you can reconfigure or resend manually.
Custom webhook payload
The JSON body contains message, risks, links, and meta. Existing fields are retained. event is test for a channel test and risk_report for a report, including reports with zero risks.
event_id is a UUID generated for each payload and retained when that payload is retried or manually requeued. version is the plugin version. Receivers may use the event ID to identify duplicate deliveries.
When a secret is configured, X-Watchdog-Signature contains sha256= followed by the hex HMAC-SHA256 of the exact request body. Verify it with a constant-time comparison before processing. The signature does not itself prevent replay; receivers should check the timestamp and event ID according to their own retry policy.
A successful HTTP response confirms acceptance by the endpoint, not downstream processing.
Troubleshooting
Scheduled scans are not running
Watchdog relies on WP-Cron to trigger scheduled scans and notifications. php or the plugin’s REST endpoint. The admin Delivery health panel shows the endpoint and generated secret.
Send the secret in an HTTP header so it does not appear in access logs; a typical example looks like this:
com/wp-json/site-add-on-watchdog/v1/cron
Testing-mode notifications also rely on this trigger, so be sure your cron job is running when validating delivery.
Discord works but email does not arrive
Email uses WordPress’s wp_mail() function and your site’s mail configuration. Discord and other webhooks use HTTP, so a working webhook does not confirm that the server can send email.
Use “Save and test email”, then check Delivery health for a mail or SMTP error. Configure your host’s mail service or an SMTP/mail plugin if needed. If WordPress accepts the test but no email arrives, check spam and your mail provider’s delivery logs, sender verification, and SPF/DKIM settings.
Acceptance for sending does not confirm inbox delivery.
CLI Usage
Watchdog bundles a WP-CLI command so you can run scans outside of the WordPress admin. All examples below assume the command is executed from a shell where wp (WP-CLI) is available.
wp watchdog scan [--notify=<bool>]
- --notify (optional): Accepts true or false (defaults to true ). When set to false, Watchdog will skip any configured email or webhook notifications and only record the scan locally.
Examples:
- Run a scan and send notifications (default): wp watchdog scan
- Run a scan silently (skip notifications): wp watchdog scan --notify=false
For automated checks, boot a WordPress/WP-CLI environment and run wp watchdog scan --notify=false to verify scanning without sending notifications. Run wp watchdog scan when you want the configured channels to receive new risk alerts.
Development
com/happyloa/site-add-on-watchdog. Clone it locally to review the source or run the test suite.