OUTCOME WATCHDOGWORDPRESS.
Outcome Watchdog verifies that automated WordPress processes produced the result they were supposed to produce. It separates execution status from business outcome status and alerts when the expected result never arrives.
A completed task is not the same thing as a completed outcome.
DOWNLOAD PLUGIN ↗LISTED RELEASE 1.1.1Automation logs prove attempts. You need proof of results.
A scheduler can fire while a post never publishes, an email never hands off, an order never appears, or an integration quietly stalls. Outcome Watchdog measures the expected count inside a fixed time window, allows a grace period, then records verified, pending, attention, failed, or recovered.
FOCUSED.
NOT BLOATED.
SIX OUTCOME SOURCES
Monitor published posts, wp_mail handoffs, WooCommerce orders, Action Scheduler jobs, named WordPress hooks, or custom heartbeats.
FIXED WINDOWS
Set the expected count, recurring window, and grace period for late work.
FAILURE + RECOVERY ALERTS
Send email or JSON webhook notifications when a monitor fails and when it later recovers.
SAFE RETRY REQUESTS
Trigger a namespaced WordPress action or outbound webhook while the connected workflow retains control of locking and limits.
HISTORY + HEALTH
Dashboard status, manual checks, event history, evaluation history, Site Health integration, and retention controls.
INTEGRATION OPTIONS
Report custom outcomes through PHP, WP-CLI, a WordPress action, or token-authenticated REST heartbeat.
Choose the real-world result, expected count, window, grace period, and evidence source.
The plugin counts qualifying outcomes while the window is open.
After the grace period, the next engine run classifies the completed window.
Failures trigger the chosen route; recovery is confirmed by a later completed window.
Evidence strength is explained.
A successful wp_mail event proves WordPress handed a message to its mailer—not inbox delivery. A named action proves the hook fired—not every downstream effect. The plugin also cannot alert while the entire WordPress stack is offline, so external uptime monitoring remains a separate job.