PromPress vs Site Add-on Watchdog

PromPress tracks various website and WordPress related metrics for collection by Prometheus, which allows you to monitor your site’s performance and health. You can even setup dashboards with Grafana and/or setup alerting via Prometheus Alertmanager. (Note: Requires Object Caching via Redis to be active, so that the plugin can store metrics.) We track a range of Website and WordPress specific metrics: Request Count Request Duration Request Peak Memory Usage External Request Duration Query Count Query Duration Plugin Updates Theme Updates Emails Sent User Count Post Count Option Count This gives you the ability to monitor the performance of your website over time and get an early warning of potential problems, like your site sending a lot of emails or the post count increasing a lot. We purposefully avoid general software and/or server level metrics which are better handled outside of the website, like detailed database metrics which is better handled via the mysqld exporter.

Site Add-on Watchdog keeps an eye on your site’s plugins and warns you when: Your installed version is two or more minor releases behind the directory build. The official changelog mentions security or vulnerability fixes. (Optional) WPScan lists open CVEs for the plugin 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. To compare public versions and changelogs, Watchdog sends one plugin slug at a time to WordPress.org and caches the response. WPScan lookups and outgoing notifications remain opt-in. Privacy first Risk processing and storage stay on your site; Watchdog does not send telemetry, site content, or user data. WordPress.org receives one request for each installed plugin slug 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. Notification channels are opt-in and send the detected plugin risks to the destinations you configure. External services Watchdog uses the following external services under the stated conditions: WordPress.org Plugin API (required for directory comparisons): During a scan, 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 (optional): When you enable Email, Discord, Slack, Microsoft Teams, or a custom webhook, Watchdog sends the alert to the address you configure. 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. Troubleshooting Scheduled scans are not running Watchdog relies on WP-Cron to trigger scheduled scans and notifications. If you have set DISABLE_WP_CRON to true or your site receives very little traffic (so WP-Cron rarely runs), configure a system cron job to call either wp-cron.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: curl -X POST -H "X-Watchdog-Cron-Key: YOUR_GENERATED_SECRET" https://example.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. 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= ] --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 Recommended workflow: on CI/CD platforms, add a job step that boots your WordPress/WP-CLI container, runs pending database migrations if needed, and then calls wp watchdog scan --notify=false to verify the plugin state without spamming production channels. Promote to production by rerunning the same command with notifications enabled when you are ready to alert your team. Development The development repository is available on GitHub: https://github.com/happyloa/site-add-on-watchdog. Clone it locally to review the source or run the test suite.