What to inspect
Start with the smallest set of facts that can explain the shopper outcome. Keep configuration and public evidence separate so a setting that looks correct does not become a fabricated pass.
- Probe limitation
- Stages completed
- Stages not reached
- Retry status
A safe verification sequence
Work from the first upstream dependency toward checkout. When an earlier stage fails, later stages are unverified—not additional problems. Repeat material failures in an independent session before interrupting anyone.
- 01
Label partial coverage
- 02
Preserve completed evidence
- 03
Retry politely
- 04
Show last successful check
Common false positives
Storefront monitoring crosses CDNs, localization, theme logic, Shopify-managed services, and merchant intent. These conditions deserve context before they become findings.
- Turning unknown into zero issues
- Cascading downstream failures
- Hiding probe limitations
How ShelfHound treats the result
ShelfHound resolves expectation from explicit merchant intent, current Shopify configuration, and then a stable observed baseline. A meaningful first failure becomes a candidate. Confirmed, independently corroborated divergence can become an issue. A blocked or incomplete probe remains unverified.
Every result keeps the product, Market or country, URL, probe stage, expected outcome, observed outcome, and time. Recovery is also proven with passing evidence; it is not inferred because an alert became old.
Frequently asked
What should I do first?
Label partial coverage. Then preserve the exact product, country, URL, and time so the next check is comparable.
Does one failed request mean the store is broken?
No. One request can fail because of a timeout, challenge, rate limit, stale session, or probe limitation. Material alerts require repeatable evidence.
Will ShelfHound change the store?
No. ShelfHound is read-only. It observes Shopify intent and the public storefront, creates only ephemeral carts when needed, and never places an order.