Incident Response Playbook for a Small Ecommerce Team

A small ecommerce team needs a simple incident playbook: name one person in charge, rate the severity, stabilize first, tell customers early, and review afterwards without blame. Write it down before you need it. In an outage, nobody thinks clearly enough to invent a process.

This playbook fits a team of two to ten people. You can adapt it in an afternoon.

What counts as an incident

An incident is any event that harms, or may soon harm, customers or sales. Examples:

• The store or checkout is down or very slow.
• Payments fail.
• Orders do not reach your fulfillment system.
• An AI feature gives wrong or harmful answers.
• A security problem, such as a hacked admin account.
• Order emails do not arrive.

If you are unsure whether something is an incident, treat it as one. You can close it fast.

Step 0: Prepare before anything breaks

Preparation does most of the work. Do these once.

• Alerting. Set up monitors for the store, checkout, certificates, DNS and key integrations. Send alerts to a channel people read.
• On-call. Decide who is the first responder each week or each day. Give them a phone number that rings.
• Contact list. Keep numbers and emails for your host, payment provider, platform support, agency and key app vendors.
• Access. Make sure at least two people can reach the admin, DNS, hosting and payment accounts. Store credentials in a shared password manager.
• Status page. Set it up before you need it.
• Runbooks. Write short guides for the likely failures.

Step 1: Define roles

In a small team one person may hold several roles. Still, name them.

• Incident lead: makes decisions, keeps order, and decides when to escalate. Does not fix things at the same time, if possible.
• Fixer: investigates and applies the fix.
• Communicator: writes status page and customer updates, and informs support.
• Scribe: logs what happens with times. In a tiny team the communicator can do this.

If you are alone, you hold all roles. Write the log anyway.

Step 2: Rate the severity

Use three levels. Define them now.

• Severity 1 (critical): customers cannot buy, or data or money is at risk. Act at once, day or night.
• Severity 2 (major): an important feature is broken or slow, but customers can still buy. Act within working hours, quickly.
• Severity 3 (minor): a small problem with a workaround. Fix in the normal workflow.

When in doubt, choose the higher level. You can lower it later.

Step 3: Respond, in order

Follow the same order each time.

1. Acknowledge the alert. Say in the team channel that you have it.
2. Open an incident thread. Use one place for all messages. Note the start time.
3. Assign roles. Say who leads, who fixes, who communicates.
4. Check what changed. Most incidents follow a change: a deployment, a plugin update, a theme edit, a DNS edit, a new app. Ask what changed in the last day.
5. Stabilize first. Restore service before you find the root cause. Roll back the change, turn off the broken feature, or switch to a fallback.
6. Communicate early. Post a status update within the first 15 to 30 minutes for a severity 1 incident, even if you know little.
7. Verify the fix. Test the store, the checkout and the affected feature yourself.
8. Resolve and announce. Close the incident and post the final update.

Quick questions to ask

• Is it only us, or is a provider down? Check their status pages.
• Is it all customers, or some? Which pages, regions or devices?
• Did it start at a clear time? What happened at that time?
• Can we roll back?
• Are orders or payments affected right now?

Step 4: Communicate

Good communication calms customers and your own team.

• Customers: post on the status page and, if needed, a banner on the site. Say what is affected, what customers can do, and when the next update comes.
• Support: give a short script and the status page link, so everyone answers the same way.
• Partners: inform your payment provider, agency or host if they can help.
• Internal: keep the incident thread up to date.

Use plain words. Do not guess the cause in public. Do not promise a fix time unless you are sure.

Step 5: Handle the money side

Think about the business impact while the incident runs or right after.

• Were orders lost? Check the admin and the payment provider for orders without payment, or payments without orders.
• Do customers need an apology, a note or a discount code?
• Did a payment get charged twice? Contact the payment provider.
• Did any personal data leak? If yes, stop and get advice. Rules such as GDPR set strict deadlines for breach reports. Ask a lawyer or your data protection contact quickly.

Step 6: Review without blame

Within a few days, hold a short review.

• Write the timeline from the log.
• Ask what happened, why it was not caught earlier, what slowed us down, and what went well.
• Focus on systems and process, not on a person.
• Decide on two to five actions. Each needs an owner and a date.
• Update the monitors, the runbooks and this playbook.

A review that ends with no actions has wasted the lesson.

Tools

You need alerting, a place for the incident thread, a status page, and a shared log. Many teams use a chat tool plus a document. For monitoring and alerts, Uptrack (from the 2folk team) is one option among others. Keep the setup small. A complex tool that nobody opens at 3 a.m. is worse than a simple one.

One-page summary

• Prepare: alerts, on-call, contacts, access, status page.
• Name the lead, fixer, communicator and scribe.
• Rate severity 1, 2 or 3.
• Acknowledge, open a thread, assign roles.
• Check recent changes. Roll back first.
• Post the first update early.
• Verify, resolve, announce.
• Check orders and money.
• Review without blame, with owned actions.

Frequently asked questions

Do I need a formal on-call rotation with only three people?

You need a clear first responder, but it can be simple. Rotate weekly, and make sure the person has working alerts on their phone. Agree on a backup when the first person is unreachable.

Should I fix the cause or restore service first?

Restore service first. A rollback or a switch-off of the broken feature is usually quicker than a root-cause fix. Find the cause after customers can buy again.

When should I tell customers about an incident?

For a severity 1 incident, post within the first 15 to 30 minutes, even with little detail. For lower levels, post if customers are likely to notice. Silence leads to more support requests.

How long should the review take?

Keep it short, about 30 to 60 minutes. The goal is a few clear actions with owners, not a long report. Hold it within a few days, while memories are fresh.