Product
The product page must respond, show a merchant journey and expose a detectable buying action.
Method
Monitoring follows the journey that actually takes revenue: product, cart, checkout, payment and confirmation. The goal is not to touch orders, but to see quickly when the funnel stops selling.
Monitored journey
CashFlowCanary checks conversion steps rather than only homepage availability. Each signal is attached to a concrete step of the WooCommerce funnel.

Each signal stays diagnostic: it helps locate the break without creating a real order or collecting customer data.
The product page must respond, show a merchant journey and expose a detectable buying action.
Add-to-cart and cart state are checked to detect blocked buttons, inconsistent sessions or emptied carts.
The payment page must load and present a usable step. A 200 page that cannot be used is still an incident.
Payment-method signals are monitored without handling card data and without exposing gateway secrets.
When the plan and environment allow it, confirmation is checked through controlled signals or sandbox scenarios, never through a real customer purchase.
Public checks and proof avoid durable actions on client stores. Risky scenarios are bounded, sandboxed or refused.
Reports discuss status, step, priority, timestamp and filtered technical proof. They must not expose customer email, named cart content, card data or secrets.
When a break appears, the goal is to produce a prioritized signal, a readable diagnosis and a report ready to hand over.
The method stays the same, but cadence, history and reports depend on context.
Monitor several client stores, hand over proof and choose the right white-label level.
Protect one site with coverage proportionate to checkout criticality, volume and expected alerts.
Compare monitors, checkout cadence, history and reports before framing monitoring.
No. CashFlowCanary observes and diagnoses the funnel. It does not replace WooCommerce, your payment gateway or your support tools.
Not by default. Tests are designed to remain non-persistent. More advanced scenarios require a controlled environment, proof of non-persistence or an explicit sandbox.
An incident with the affected step, priority, filtered technical context, shareable proof and a recommended next action.