Commerce OS guide

Store Health

Guide status: Operational guidance. Last reviewed 14 August 2026. Implemented checks and remediation links vary by installed version, permissions and Shopify theme.

Purpose

Store Health separates conditions that prevent Liva 7 from operating correctly from ordinary commercial uncertainty. It helps identify whether a problem belongs to connection, data, configuration, placement, measurement or service availability, then routes the team towards a safe next step.

A health state should describe an observable condition. It should not imply that weak commercial performance is a technical fault or that every incomplete measurement is an incident.

Before you begin

  • Confirm the store, active theme and affected workspace or placement.
  • Record when the issue was first noticed and whether it is continuous or intermittent.
  • Preserve the current customer experience before changing configuration.
  • Do not send passwords, access tokens or unnecessary customer information in diagnostics.

Work through the layers

  1. Connection: can Liva 7 reach the required Shopify or internal service?
  2. Permission: does the current installation have the access required for the operation?
  3. Data: are the relevant records present, fresh and eligible?
  4. Configuration: is the decision, content or policy complete and valid?
  5. Placement: is the intended app block, embed or theme surface installed and published?
  6. Delivery: can an eligible storefront visit receive the experience?
  7. Measurement: are valid events available and processed for the selected window?

Work in this order because a downstream symptom can be caused by an upstream fault. Repeatedly editing content will not repair a missing placement, and republishing a placement will not create missing source data.

Severity and state

Distinguish an informational condition from degraded operation and a customer-affecting failure. Unknown or Learning may be valid operating states; they become health concerns only when evidence should be available and is not.

For each issue, record the affected scope, last successful state, current evidence, attempted checks and owner. A “fixed” state should require verification at the same layer where the problem appeared.

Safe use and fallback

Prefer reversible diagnostic changes. Do not repeatedly uninstall, republish or widen permissions without evidence that the action addresses the failing layer. If storefront delivery is unsafe, use the approved default experience and keep the issue visible internally.

You are finished when

  • the failing layer and affected scope are identified;
  • the customer-facing fallback is safe;
  • the repair is verified rather than merely saved; and
  • enough context is recorded to diagnose recurrence.