When WooCommerce revenue breaks, see the sequence — not just the symptom.

Orders stopped, the checkout page still loads, and the gateway says everything is fine. This puts the change, the signal that started failing after it, and the revenue that stopped on one timeline — then tells you whether the fix held.

Start the free beta — about 10 minutes See the MCP tools Request beta access

Free beta · no card · the collector sends aggregate signals, never customers, orders, or payment details.

Controlled free beta is live. The MCP endpoint is public and read-only; store connection remains invite-only until a real-store pilot verifies the collectors and diagnostic accuracy. See the current operational state.

illustrative Install, connect, ask, answer — on an invented store. Real-store accuracy is unmeasured.

Getting started

From "orders stopped" to an answer, in about ten minutes

Controlled free beta is live. The public MCP endpoint is available, but connecting a store is deliberately administrator-issued: a store credential is created once, handed directly to the store owner, and cannot be recovered later. Step 2 is where a store joins.

1

Install the plugin on the store

Read-only. It makes no outbound request at all until someone connects the store.

Installation guide
2

Connect with a credential an administrator issues

Whoever operates the service issues it from an admin-only route and hands it over once — the service keeps a hash, so it cannot be shown again. Paste it into Tools › Checkout Diagnostics. The first aggregate snapshot arrives within fifteen minutes.

What connecting sends · Ask for access
3

Add the MCP endpoint and ask

Point an AI client at the deployment's /mcp and call get_checkout_health_snapshot. It is free, needs no credential to try, and tells you whether a full diagnosis has anything to work with. With no store connected it answers connected: false and points back at step 1 — which is the correct answer, not an error.

Endpoint and schemas

If you run the store

Install the plugin, enter the credential you were issued, and wait for the first snapshot. You will not see a diagnosis before the store is connected, and the tools say so rather than guessing.

If you are wiring up an agent

Add the MCP server and call the free health snapshot first. With no credential it answers connected: false and points at setup — which is the correct answer, not an error. A credential is scoped to one store and issued by that store's operator.

What an answer looks like

One store, one window

The sequence is the diagnosis: a change, then the signal that started failing after it, then the revenue that stopped. Every line below is computed by the same engine that answers diagnose_revenue_incident.

Illustrative demo · accuracy not yet measured

Real reasoning, invented store — rendered by the engine that answers diagnose_revenue_incident.

change · 5 h before plugin:woocommerce-gateway-stripe updated to 9.6.0
webhook · 30 min before webhook payment_intent.succeeded failing (41 consecutive)
scheduler · 4 min before woocommerce_scheduled_subscription_payment backlog begins
what it concludes illustrative Payments are being taken but the webhook that advances the order is not being delivered, so orders stay in pending.

illustrative 4 observations across 3 signal families agree. 2 independent public origins report the same regression.

Then: Re-run verify_revenue_recovery after 2 hours: pending should fall relative to processing, and consecutive webhook failures should return to zero.

Why this and not the WooCommerce MCP

Reading orders is solved. Explaining them is not.

WooCommerce already ships an MCP that reads and writes orders and products. Asked "how many orders are pending?", it answers perfectly — and that is the question you ask after you already know something is wrong.

What a store knows alone

Something broke here. Not what ships broken, not whether anyone else has seen it, not which of last week's three updates did it.

What the public record knows alone

This version is reported broken. Not whether you run it, not whether your orders actually stopped, not when.

The join is the product: "the webhook started failing four hours after that update, and two independent origins report the same regression in that version" is a sentence neither side can produce by itself.

The boundary

It never sees a customer, an order, or a payment

Read-only, and blind by construction. It cannot change an order, a refund, or a plugin — and it never receives a customer, order or payment identifier, because the store's collector does not send one.

What a connected store sends

Counts of orders by status per hour. Counts of status transitions, with timings only where there are enough orders that no single one can be picked out. Order-note reason codes from a fixed list of nine. Whether each gateway is available. Webhook success and failure counts. Scheduler backlog. Whether the checkout page is published and contains a checkout. Which plugins, themes or core versions changed, and between which versions.

What never leaves the store

No customer name, email, phone, address or IP. No order numbers or contents. No card or payment details. No payment, charge or session identifiers. No keys, cookies or webhook URLs. No log files. No paths. Order note text is classified on the store and then discarded — only the label travels.

A snapshot carrying any of those is refused whole rather than cleaned and stored: accepting a scrubbed version would teach the sending plugin that identifiers are fine, and the next version would send more. The exact field list.

Outcomes

What it says, including when it will not answer

The five below are what an agent meets most. 8 more are one click away, and most of those are refusals — the states where this service declines are what make the states where it answers worth anything.

Not connected No store is connected, so there is nothing to diagnose. Install the plugin, connect the store, and the first snapshot arrives within fifteen minutes.

More outcomes (8)

Not enough history yet — Connected, but only one snapshot has arrived. Change over time is most of the signal; there is nothing to compare this against yet.

Thin coverage — Only one signal family reached this service. One family is a coincidence with a narrative attached — at least two are needed before a cause can be separated from one.

Stale snapshot — The most recent snapshot is over six hours old. Diagnosing a live incident from stale aggregates produces a confident answer about a store that has since changed.

Two changes, neither blamed — Two components changed before this started. Which one is responsible cannot be told apart from these signals, and picking the more plausible one would be a guess with a citation stapled to it.

Card testing, not lost sales — The failure burst is concentrated on one decline reason in one short window with almost no successful orders alongside. That reads as card testing rather than buyers who could not pay — some of this volume is not lost revenue.

Real drop, no cause — Paid orders fell sharply and nothing in the signals explains it. The drop is reported; nobody is blamed for it. Marketing, stock and seasonality are all outside what this service can see.

Fix held — Since the change: webhook failures back to zero, pending orders down, paid orders recovered. Confirmed over four hours of traffic, not four quiet minutes.

Upload refused — A snapshot arrived carrying something that could identify a customer, an order or a payment. It was refused whole — not cleaned and stored — and nothing from it reached the database.

The answer itself

Example incident packet

What an agent actually receives: a timeline, ranked hypotheses with the observations behind each, independent public sources where they exist, what argues against the answer, what remains unknown, safe next steps, and how to tell whether the fix held.

See the full packet an agent receives

Illustrative demo · accuracy not yet measured

Rendered from the current engine on an example store. The reasoning is the product's own; the store and the sources are placeholders.

Symptom: payment succeeded order pending
Data freshness: fresh
Signal families: 8 of 8
Window: 12 hours

What happened, in order

change 5 h before now plugin:woocommerce-gateway-stripe updated to 9.6.0
webhook 30 min before now webhook payment_intent.succeeded failing (41 consecutive)
scheduler 4 min before now woocommerce_scheduled_subscription_payment backlog begins

Invented store — accuracy on real stores is unmeasured high confidence

Payments are being taken but the webhook that advances the order is not being delivered, so orders stay in pending.

What the store's own signals show

Webhook "payment_intent.succeeded" is active after 41 consecutive failures (last response 5xx). strong
18 order notes classified as webhook missing. supporting
14 order notes classified as authorized not captured. supporting
pending → processing is taking up to 85 minutes at p90. supporting

Independent public evidence (2 origins)

Illustrative source A — github issue, fixed in 9.6.1. not a real link
Illustrative source B — wporg forum, fixed in 9.6.1. not a real link

On a real answer these are live URLs to the issue or thread. Here they are placeholders: linking a fabricated example to real reports would misrepresent both.

What is still unknown

Whether the gateway's own dashboard shows the charge as captured — this service does not read it.

Safe next steps

In WooCommerce → Settings → Advanced → Webhooks, open the failing topic and check its recent delivery log.
Re-enable the webhook if it was auto-disabled after repeated failures.
Re-send one recent delivery and confirm the order advances, rather than editing order status by hand.

How to tell whether it held: Re-run verify_revenue_recovery after 2 hours: pending should fall relative to processing, and consecutive webhook failures should return to zero.

Limits

What it will not do, and what it cannot see

Will not

Guess during an outage. Stale data, one signal family, or signals supporting no cause all produce an abstention with a reason.
Blame the plausible one. Two components changed before the break? It names both and says it cannot tell them apart.
Call silence a recovery. A quiet ten minutes is "unknown", not "resolved".
Touch anything. Every tool is read-only.

Cannot see

Marketing spend, stock levels, seasonality.
A gateway's own dashboard.
Anything on a store that is not connected.
Whether its own diagnoses are right on real stores — that is unmeasured, and said so rather than estimated.

When WooCommerce revenue breaks, see the sequence — not just the symptom.

From "orders stopped" to an answer, in about ten minutes

Install the plugin on the store

Connect with a credential an administrator issues

Add the MCP endpoint and ask

If you run the store

If you are wiring up an agent

One store, one window

Reading orders is solved. Explaining them is not.

What a store knows alone

What the public record knows alone

It never sees a customer, an order, or a payment

What a connected store sends

What never leaves the store

What it says, including when it will not answer

Example incident packet

What happened, in order

Payments are being taken but the webhook that advances the order is not being delivered, so orders stay in pending.

What the store's own signals show

Independent public evidence (2 origins)

What is still unknown

Safe next steps

What it will not do, and what it cannot see

Will not

Cannot see