---
title: Keep catalog browsing available during database outages
url: https://namegarage.com/blog/static-browsing
author: Namegarage
date: '2026-11-10'
description: Static browsing uses deployed snapshots while purchase actions verify
  current prices and availability.
ai-disclosure: ai-assisted
---

# Keep catalog browsing available during database outages

This article was prepared with AI assistance and reviewed by a person before publication.

Catalog browsing should stay available when the transaction database is busy. A live availability check had entered the page-serving path, so a database queue failure could return an error before the static page reached the visitor.

The fix captures publication state and known unavailable domains during a guarded site build. The homepage, domain pages, Deals page, numbered catalogs and JSON browsing catalogs read that deployed snapshot. An open Deals page refreshes from the same browsing catalog. Prepared price schedules still use server time, including their start and end boundaries. Those requests make no transaction-database calls.

A browsing snapshot can age between deployments. Purchase actions therefore continue to verify current prices, funded reservations and publication revisions before proceeding. If the database cannot verify a purchase, the action refuses safely and the browsing pages remain available. Existing buyers retain their saved purchase-recovery paths.

Live search can also disagree with the deployed snapshot. The browser reconciles that snapshot once instead of repeatedly hiding and restoring results. When live search cannot verify prices, it keeps the notice and waits for the server's retry delay. Hidden tabs do not retry. A successful static catalog read does not imply that the transaction database recovered.

Activating or withdrawing a price-drop collection requires a new guarded deployment to update browsing. The upload guard rejects a snapshot if publication state changed during its build. An outage prevents a new verified build; it does not invalidate the pages already deployed.

Local acceptance exercises the actual Workers runtime with synthetic inventory and an isolated database. It checks scheduled prices and known reservations, then removes database tables and verifies that browsing still succeeds while dynamic price checks refuse. Separate fault tests cover database calls that throw, reject, never settle, or have no binding. No production outage is induced.