Make the first decision before making the first change
When a Magento store fails during trading, several people may begin fixing different things at once. Hosting restarts a service, a developer clears cache, marketing changes a tag and customer support asks shoppers to retry payment. Each action may be well intentioned, but together they can obscure the cause and create new business uncertainty.
A practical incident response plan gives the team a shared sequence: establish impact, assign an owner, preserve useful evidence, choose containment, verify recovery and reconcile affected activity. It does not need to be a large document. It needs to be accessible when the store is unavailable and specific enough that people know who can authorise a change.
Define impact in terms of customer and staff journeys
Describe what is unavailable or unreliable. Can customers browse but not pay? Is one payment method affected? Are orders being accepted but not reaching fulfilment? Is the store slow only for one country or customer group? These distinctions determine which people and systems need attention first.
Use a few business severity categories that your team understands. For example, an inability to accept orders is different from an isolated image fault, although both may need work. Do not create a severity label that implies a guaranteed response time from an external supplier unless that commitment actually exists. The plan should show current support arrangements and escalation routes accurately.
- 01OwnName the incident lead and business decision maker
- 02ContainLimit harm while preserving useful evidence
- 03RestoreVerify the complete trading journey
- 04LearnReconcile exceptions and assign follow-up work
Assign roles and keep one change record
Name an incident coordinator, a technical lead and a person responsible for customer or internal communication. In a small business, one person may cover more than one role. The important point is that the decision owner and the latest verified state are clear. Keep a timestamped log of observations, decisions and changes.
Record the time zone, who made each change, its purpose and the result. A short factual entry is more useful than an unstructured chat containing contradictory theories. Include the release identifier or configuration detail needed to reverse a change. Where different suppliers own the application, infrastructure and payment integration, document their boundaries before an incident occurs.
Prepare access and evidence without spreading secrets
Maintain a current inventory of the systems needed for recovery: domain and DNS, hosting, application repository, deployment process, monitoring, payment provider and key integrations. Record the authorised owners and the secure route to access. The incident plan itself should not contain a collection of passwords or unrestricted customer exports.
Preserve relevant logs and monitoring before retention windows or recovery actions remove them. Capture a small number of representative failures with timestamps and identifiers. If a security incident is suspected, involve the appropriate security response owner; an ordinary availability playbook should not be treated as a substitute for evidence preservation and containment decisions specific to compromise.
Separate containment from the permanent fix
Containment aims to reduce current harm. It may involve pausing a problematic import, reverting a compatible release or disabling one affected feature through an authorised and reversible route. A permanent correction addresses the demonstrated cause and its prevention. The two may be delivered at different times, and the incident log should make that clear.
Before containment, state the expected benefit, commercial consequences and rollback condition. A disabled delivery option may restore checkout for some customers but exclude others. A code rollback may be unsafe after incompatible database changes. The plan should prompt these questions rather than prescribe “restart everything” as the standard first step.
| Field | What to record |
|---|---|
| Impact | Affected journeys, start time and customer scope. |
| Ownership | Incident lead, technical owner and authorised decision maker. |
| Evidence | Timestamps, relevant errors and a controlled change log. |
| Recovery | Observed working journeys and remaining limitations. |
| Reconciliation | Affected payments, orders, stock and customer messages. |
| Follow-up | Root-cause work, preventive changes and named owners. |
Give payments and orders a separate reconciliation step
An error page does not establish whether a customer paid or an order was created. During checkout incidents, maintain a bounded list of uncertain transactions for authorised reconciliation. Match provider and Magento records before asking customers to retry, releasing fulfilment or issuing refunds. Do not use manual status changes as a substitute for understanding the actual outcome.
The payment mismatch guide and webhook failure guide cover related investigations. Where orders reach Magento but not downstream systems, follow the ERP/WMS synchronisation guide. Recovery includes the work left between systems, not just the visible storefront.
Communicate what is known and when the next update will come
Use plain language about the affected service and current customer impact. Distinguish an observed failure from a suspected cause. Avoid declaring a resolution time that the technical team has not established. An agreed next-update time can be useful even when a repair estimate is uncertain, because it prevents repeated requests for the same status.
Prepare internal wording for customer support. If payment outcomes are uncertain, the team should not automatically tell every shopper to pay again. If a temporary workaround is safe and authorised, describe its limits. Keep operational messages free of credentials, private logs and speculative blame. After recovery, communicate the verified state and any remaining restrictions.
Verify the original failure and the adjacent journeys
Recovery checks should begin with the journey that failed, under the relevant conditions. Then confirm the neighbouring paths that a containment might have changed: product selection, basket totals, delivery, payment, confirmation and fulfilment handoff where applicable. Use appropriate test facilities and controlled authorised actions rather than generating unnecessary live financial activity.
Check monitoring and backlogs as well as the interface. A storefront may look healthy while queued orders or emails continue failing. Decide how long to observe the recovered system based on the incident pattern and business workload. A quiet successful request is not proof that a load-related issue is permanently resolved.
Turn the incident into a small set of owned improvements
Hold a factual review after the urgent work is complete. What first alerted the team? Which evidence was missing? Which change restored service, and how confident are you about the cause? Identify improvements with named owners and acceptance criteria. A long list of vague recommendations is less useful than a few actions the team can actually complete.
Examples include an alert for a failed critical journey, a release test for the affected basket, documented rollback compatibility or a reconciliation report for delayed payment events. These are potential controls, not claims that every incident needs every tool. If recurring performance pressure remains unexplained, a Performance Investigation can help prioritise the next work.
Keep the plan current and easy to find
Review contacts, access owners and recovery assumptions after material platform or supplier changes. Run a short tabletop exercise: describe a fictional checkout outage and ask the team what it would do. That can expose a missing contact or unclear approval boundary without placing production under artificial load.
For an incident happening now, use the Midoriweb emergency support route and provide the essential facts first. Acceptance, scope and availability must be confirmed through the service process. A prepared plan makes that conversation clearer; it does not replace the actual support terms or promise immediate resolution.
Common questions
Does a small store need a formal incident plan?
It needs a usable plan, which can be short. Named owners, secure access routes, a change log and clear recovery checks are more valuable than a lengthy document nobody can find.
Should we pause all changes during an incident?
Pause unrelated work and coordinate necessary recovery changes through the incident owner. The purpose is to preserve control and causality, not to prevent an authorised fix.
When is an incident really closed?
When the affected journeys and business records have been checked, remaining limitations are communicated and follow-up work has owners. A green homepage alone is not a complete closure test.
Technical references
Use the documentation that matches your installed version, payment provider and deployment.