Can your store actually take an order right now?

No, and it is worth explaining how that is enforced. The code path calls no order-creating API: there is no wc_create_order(), no checkout process and no gateway payment call anywhere in the plugin. While the rehearsal runs, a guard is armed that short-circuits outbound mail, replaces the WooCommerce mailer with a no-op, refuses outbound HTTP and aborts the entire run with a logged error if anything tries to insert an order. The cart teardown and session restore run in a finally block, so they happen on success, failure and exception alike.

No. The free plugin is read only, deliberately. It writes two options of its own, its settings and its last report, and nothing else. There is no code path that writes a WooCommerce setting, a product, a coupon or an order. It shows you what is wrong, tells you what a customer sees, and links you straight to the setting so you can make the change yourself.

Neither. The free plugin has no email feature at all: not on activation, not after an audit, not ever. It makes no outbound HTTP request of any kind, so there is no telemetry, no licence check and no update ping. It is fully useful on a store with no internet-facing traffic.

The System Status Report describes your environment: PHP version, memory limit, template overrides, database tables. Preflight describes your shop: whether the configuration lets a customer complete a purchase. The System Status Report also lists everything at the same weight, which is why core issue #26371, asking for severity filtering, has been open since 2020. Preflight's whole output is severity.

Yes, within a documented cap. The catalog check reads at most the configured number of published products per run, newest first, and stops at its 15 second time budget. The cap and the budget are both stated in the UI, so the number you see is never quietly partial. The paid add-on's hygiene sweep batches across the whole catalog for stores that need the full pass.

Both. Preflight detects which one the assigned checkout page actually renders, reports it, and raises a warning when the page contains neither, which is the usual symptom of a page builder rendering the form through a widget of its own.

Yes, and it declares compatibility for both HPOS and the cart and checkout blocks. Preflight does not read orders at all in this version, and everything it does read goes through WooCommerce's own APIs rather than raw postmeta.

It makes one of the forty-seven assertions a second opinion on WooCommerce 11.1.0 and later, and it leaves the other forty-six alone. It is also good news: core shipping a merchant-facing warning of exactly this shape is a strong signal that the category is real. Preflight's shadowing check stays because the stores running older versions are the ones most likely to need it.

Continuity, history, scope and workflow. Scheduled re-audits that alert only when a finding appears, worsens or clears. A change log of who altered which WooCommerce setting, with a diff and a revert. Your own custom rules. A branded printable client report for handovers. A dashboard aggregating several stores you own, over authenticated site-to-site requests with no third-party service involved. A batched hygiene sweep for large catalogs. It unlocks no check that the free plugin pretends to have.