Grumpy AI Gate vs Site Add-on Watchdog

Grumpy AI Gate helps you stay in control as AI features spread across WordPress. It observes and intercepts outbound HTTP that other code on your site already initiates (plugins, themes, or core)—so you can see which plugin was involved, how much activity you are seeing (including helpful estimates), and optionally stop unwanted WordPress AI Client traffic for specific plugins. This plugin does not call external AI APIs for its own dashboard, analytics, or licensing. Nothing is sent to us or to a third-party analytics service. Why use it Visibility — Dashboard summaries, a per-plugin usage table, and a request log so surprises become visible early. Spend awareness — When other software calls paid APIs, usage adds up. Logging helps you notice patterns before invoices or quotas become a problem. Safer sharing — Knowing what leaves your server makes it easier to decide what belongs in prompts and what does not. Optional blocking — For paths that use WordPress’s AI Client, you can block generations from selected plugins under Grumpy AI Gate → Settings (save to apply). How it works When the WordPress AI Client is available, the plugin records those requests from core lifecycle hooks (other code still drives the actual generation). For HTTP fallback, Grumpy AI Gate hooks WordPress’s HTTP API (for example pre_http_request) to inspect requests that are already in flight. If a URL matches built-in recognition rules for major AI providers, a log row can be stored. Grumpy AI Gate does not open those connections for its own purposes—it only filters and classifies traffic initiated elsewhere on the site. HTTP fallback does not block outbound API calls in the current release—it is there so you still get visibility when plugins talk to providers directly over HTTP instead of (or in addition to) AI Client flows. Compatibility The plugin requires WordPress 7.0+ (matches Requires at least in the plugin header). On WordPress 7.x, it works with core AI Client functionality where available. Release testing included WordPress 7.0 Beta 5. HTTP fallback remains important on every supported version—it records calls to recognized provider endpoints that other plugins make directly over HTTP, which is still common alongside (or instead of) AI Client–based flows. Privacy Everything is stored locally in your WordPress database. There is no cloud account, no telemetry, and no third-party analytics from this plugin. For technical details on logging, double-counting avoidance, and blocking limits, see the FAQ below. External services This plugin does not rely on third-party AI APIs, remote analytics, or any external service for its own features. All logging and settings stay on your site. Provider names and URL patterns included with the plugin are local matching rules only. They let Grumpy AI Gate filter and classify outbound HTTP requests that plugins, themes, or WordPress core may already be sending. They are not a list of servers this plugin calls to power the admin UI or to “phone home.” Your site may still contact third-party AI providers when you or other software use AI features—that traffic is separate from this plugin’s own network use (which does not include calling those providers for monitoring).

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.