Safe Fallbacks
Guide status: Reliability contract. Last reviewed 14 August 2026. Actual fallback behaviour must be tested for every implemented storefront surface and action domain.
Purpose
A safe fallback preserves a coherent customer and merchant experience when evidence, eligibility, configuration or a required service is unavailable. Fallback is part of normal product design, not an afterthought used only after an incident.
Fallback principles
- Preserve usefulness: customers should still be able to understand, navigate and buy.
- Prefer approved defaults: use merchant-reviewed content and Shopify-native behaviour where appropriate.
- Fail closed for material change: uncertain authority, price, eligibility or target state should produce no unapproved change.
- Keep diagnostics internal: do not expose error codes, decision states or customer classifications on the storefront.
- Record the reason: operators need to know whether fallback resulted from Unknown, Unavailable, invalid configuration or a service failure.
Design a fallback
For each surface, identify the default content or Shopify behaviour, the conditions that trigger it, the customer-visible result, the internal state and the recovery owner. Test missing data, ineligible customers, unavailable products, slow or failed services, long content, mobile widths and expired configuration.
For automated actions, define the last point at which work can stop without leaving a partial state. If a multi-step action cannot complete, the record should show what did and did not occur. Restoration or compensation must not be assumed unless it is implemented and verified.
Common safe patterns
- Show approved general content when audience eligibility is unknown.
- Omit an unavailable recommendation without leaving an empty layout.
- Retain Shopify's valid price and purchase controls when enhancement data cannot load.
- Keep a recommendation pending when authority or publication state cannot be confirmed.
- Display a timestamped last-known value internally only when staleness is explicit and safe.
Unsafe patterns
Do not invent values, present stale information as current, block the purchase path, show broken placeholders, retry an externally billed action without limits, widen permissions automatically, or report an action as live solely because a request returned successfully.
Verify recovery
Recovery is complete only when the failing dependency is healthy, the intended experience is verified and measurement integrity has been assessed. Remove fallback state based on evidence, not elapsed time alone.
You are finished when
- every important surface has an approved default;
- failure does not create a misleading or blocked customer journey;
- operators can distinguish fallback causes; and
- recovery and live verification are testable.