What should a Shopify store put in an accessibility alert runbook for weekends?
A weekend runbook should fit on one page: three severity tiers with concrete examples, one named primary and one escalation path, and the first three checks to run before touching any code. The goal is not to fix everything on Saturday. It is to make sure nothing urgent waits until Monday while nothing minor gets an emergency deploy.
Write the tiers with examples, not adjectives
Severity tiers fail when they use words like major or significant. Use examples instead. P1: a checkout step unreachable by keyboard, a screen reader trap on the payment page, any barrier that blocks completing a purchase. P2: a template-wide issue on product or collection pages, missing form labels on account pages. P3: a single decorative image missing alt text, a contrast issue on a rarely visited page.
The tiers drive everything else: P1 pages the primary immediately and can trigger an emergency deploy, P2 goes into the Monday queue with a note, P3 becomes a ticket. When the examples are concrete, the on-call person classifies in seconds instead of debating definitions at midnight.
Name one primary and one escalation
A runbook that says contact the team is a runbook that pages nobody. Name one primary on-call person per weekend, with a backup. The primary acknowledges within an agreed window, usually 30 to 60 minutes for P1. If the primary does not acknowledge, the backup is paged automatically.
Keep the escalation path short: primary, backup, then the store owner or agency lead. Three levels is enough. Every additional level adds delay without adding information, and weekend incidents are won or lost on the first response.
The first three checks before any fix
Check one: reproduce in a clean session. Open an incognito window, disable extensions, and try the failing flow. Alert systems occasionally flag issues caused by the test environment itself, and a weekend deploy based on a phantom costs more than the alert.
Check two: find the trigger. Was there a deploy, an app install, or a content change since the last clean scan? Most weekend P1s trace to something that shipped Friday afternoon. Check three: scope it. Is the issue on one page, one template, or the whole site? The answer determines whether this is a revert candidate or a surgical fix.
Decide in advance what can wait
The hardest weekend call is choosing not to act. Write the wait criteria into the runbook: no P1 on a revenue path waits, but a P2 on a low-traffic template can wait if the Monday queue is confirmed. The runbook should say who has authority to make that call, so the primary is not second-guessing at 1 AM.
Waiting is not ignoring. A deferred alert gets a dated ticket, an owner, and a Monday morning review. The runbook should include the exact handoff format: what was observed, what was checked, and what the recommended Monday action is.
Keep the deploy rules strict on weekends
Weekend deploys should be narrower than weekday ones. The runbook can allow a revert, which restores a known good state, but should require a second pair of eyes for any forward fix. Emergency forward fixes on tired engineers at midnight are how new P1s are born.
If a forward fix is unavoidable, the runbook should require a verification pass against the original alert before closing the incident: re-run the failing check, confirm the fix in a clean session, and note the deploy in the incident log.
Review the runbook every quarter
A runbook rots. Staff change, the app stack changes, the alert system gets reconfigured. Review the tiers, the examples, and the contact list quarterly, and update the examples with real incidents from the previous quarter. The best runbook examples are the ones that actually happened.
After every weekend incident, add one line to the runbook if something was ambiguous. Runbooks improve by accretion: each incident makes the next one faster. A runbook that never changes is a runbook nobody uses.
Frequently asked questions
What should I know about write the tiers with examples, not adjectives?
Severity tiers fail when they use words like major or significant. Use examples instead. P1: a checkout step unreachable by keyboard, a screen reader trap on the payment page, any barrier that blocks completing a purchase. P2: a template-wide issue on product or collection pages, missing form labels on account.
What should I know about name one primary and one escalation?
A runbook that says contact the team is a runbook that pages nobody. Name one primary on-call person per weekend, with a backup. The primary acknowledges within an agreed window, usually 30 to 60 minutes for P1. If the primary does not acknowledge, the backup is paged automatically.
What should I know about the first three checks before any fix?
Check one: reproduce in a clean session. Open an incognito window, disable extensions, and try the failing flow. Alert systems occasionally flag issues caused by the test environment itself, and a weekend deploy based on a phantom costs more than the alert.
What should I know about decide in advance what can wait?
The hardest weekend call is choosing not to act. Write the wait criteria into the runbook: no P1 on a revenue path waits, but a P2 on a low-traffic template can wait if the Monday queue is confirmed. The runbook should say who has authority to make that call, so the primary is not second-guessing at 1 AM.