Manage an integration outage with accurate status messages

During an integration outage, show what the software actually knows. A portal can cushion an outage, but it should not display unfinished ERP processing as a completed order. Traceable states and a controlled resumption matter.

Establish the last reliably recorded state

In a fictional portal, a customer submits an order creation request. The ERP is temporarily unreachable. From its own reliably recorded processing state, the portal must be able to determine whether the request has been accepted. A display alone does not store a request.

These states are our example model. The labels must fit the application's actual evidence. A quick, successful HTTP receipt alone does not establish completed order creation.

Associate retries with the same operation

If a customer resubmits because the display remains unresolved, the application must be able to recognise whether the same order is intended. Specify the identifier, its scope and the handling of requests already processed. Stripe describes repeated event deliveries as a specific webhook case; this does not establish a universal retry rule for your ERP.

Check in particular the case where the ERP order was created but its response was lost. A retry must not trigger a second creation without checking.

Assign responsibility and communication

Determine who assesses an outage, who authorises processing to resume and who updates the visible status. The Google SRE Workbook distinguishes incident resolution from coordination and communication. A small team can combine roles but still needs clear responsibilities.

Resume in a controlled way after recovery

ERP reachability is the starting point for checking. Resolve open and already processed requests before executing queued work again. Display confirmed only when the corresponding evidence exists.

Test an outage before storage, an outage after storage and a lost ERP response. Check the visible portal status and the actual number of orders created. This shows whether the response remains accurate when a customer experiences the outage directly.

Sources

• Google SRE Workbook: Incident Response

• Stripe: Webhooks