The first question in any Shopify incident is always the same: "What changed?" The problem is that without a systematic record, you're relying on Slack memory and everyone's ability to recall what they did in the last four hours.
The core framework
Effective Shopify incident response follows a simple four-step loop: detect, scope, correlate, resolve. Most teams are good at detecting (your monitoring tools handle that) and resolving (your engineers know what to revert). The gap is almost always in scoping and correlating.
Step 1 — Scope the incident window
Before you do anything else, establish a time window. When did customers first report the problem? When did your monitoring first fire? Set those as your boundaries. Everything that changed in that window is a suspect.
Step 2 — Pull the change list
With a time window in hand, you need a list of everything that changed. Theme publishes, app updates, script edits, discount rule changes, vendor actions, code deploys — all of it. If you don't have a change log, you're reconstructing this from Slack, which takes time you don't have.
Step 3 — Correlate with symptoms
Cross-reference your change list with the symptom timeline. A checkout error that started at 14:05 is much more interesting if someone deployed a theme update at 14:02. This is where most incidents get resolved — not because you found the bug, but because you found the change that introduced it.
Step 4 — Resolve and document
Once you've identified the likely cause, revert or fix it. Then — critically — document what happened while it's fresh. A brief incident note attached to the offending change is worth more than a detailed post-mortem written three days later.
The post-mortem that actually gets read
Attach your incident summary directly to the change log entry. Include: what changed, when, who made the change, what broke, how long it took to detect, how long to resolve, and what's changing in process. Keep it to a single page.