# Claude is back. Your business still needs a recovery plan > Claude's September 22 incident is resolved. A practical guide explains how businesses can maintain limited service, preserve unfinished work and recover their own backlog after an AI outage. By BIG CHANGE Editorial Published: 2026-09-22T08:51:37.833Z Updated: 2026-09-22T08:51:37.833Z Canonical: https://bigchange.ai/blog/claude-outage-ai-business-continuity ![An intact desktop document machine sits beside an open ledger with an orange bookmark and an orderly stack of folders.](https://bigchange.ai/api/media/file/preserved-work-hero-v1.png) AI-generated conceptual illustration by BIG CHANGE. When an AI service pauses, a business still needs accessible records of unfinished work. The bookmarked ledger represents preserving the stopping place. Conceptual illustration, not evidence of damaged equipment or lost data. Claude experienced elevated errors across multiple models on September 22. Anthropic’s final incident update puts the impact window at 00:50 to 02:10 UTC, or 80 minutes. It marked the incident resolved at 02:35 UTC. The affected components listed included claude.ai, the API, Code and Cowork. The record does not say every request failed, and it contains no published explanation of the root cause. [Anthropic’s incident record](https://status.claude.com/incidents/7g1qpkyz5gxh) For a business using AI inside a working process, service restoration answers only part of the problem. Customer requests may still be waiting. Someone may have started handling a case manually while an automated attempt remained active. A supervisor needs to know which work can resume and which requires inspection first. An occasional unavailable assistant is inconvenient when it helps someone brainstorm. When the same service helps classify incoming cases, draft replies and update records, interruption becomes an operating problem. The useful preparation is a small continuity plan that staff can follow without access to the AI service itself. This guide uses a hypothetical customer-service desk to show how that plan could work. The procedures are proposals to adapt and rehearse, not a test BIG CHANGE performed or a description of customers affected by this incident. ## Choose the service you can maintain without AI Imagine a small equipment supplier whose assistant categorizes incoming support messages and prepares responses from approved product information. Staff review replies before sending them. The business depends on the system to organize the queue, even though people remain responsible for the answers. If the assistant stops responding, the manager’s first decision is what the desk can still promise. Staff might continue acknowledging requests and handling cases with imminent deadlines while postponing routine product explanations. They need access to the original messages and approved reference material outside the assistant. Otherwise, “switch to manual” is an instruction without the means to carry it out. Choose that reduced service in advance. Name the person who can activate it, the work that should pause, and the staff who will cover the remaining tasks. Set a review time so a temporary arrangement does not drift through the afternoon without anyone reassessing it. Customer-facing notices should explain the delay and the available route for urgent help, with promises the team can keep. Google’s engineering guidance on overload describes serving reduced functionality, limiting traffic and prioritizing important requests when resources are constrained. Those are established reliability techniques, not a diagnosis of this Claude incident. Applied to a service desk, they support a deliberate reduction in scope when normal processing cannot continue. [Google SRE: handling overload](https://sre.google/sre-book/handling-overload/) The reduced service also needs a capacity limit. Two people cannot silently inherit the workload of an automated system that normally serves many more requests. Record what they can handle, what will wait and when additional help becomes necessary. Customers benefit more from a credible response window than an automated acknowledgment that suggests normal service continues. ![Two rightward arrows connect a lowered stop lever, a folder under a magnifying glass, and a tray of work beside a raised lever.](/api/media/file/pause-review-restart-inline-v1.png) ## Keep a record of work outside the conversation The service desk needs a case record it can read while the model is unavailable. That might be its existing support system. The important property is that the business can establish what happened without asking the interrupted assistant to reconstruct it. For each case, preserve the original request, the person or process responsible, and the last confirmed action. A saved draft is different from a sent response. A proposed change to a customer record is different from a change confirmed by that system. Store the evidence needed to tell them apart, with the same access restrictions the underlying customer information requires. During an interruption, separate work into these practical categories: - Ready to start: no processing or external action has begun. - Partly prepared: a classification or draft exists, but the next step is unfinished. - Confirmed complete: the destination system records the intended action. - Uncertain: an action was attempted, but confirmation is missing. Assign uncertain cases to someone who can inspect the relevant system before resuming them. If the assistant was preparing a reply when a connection failed, a new draft may be harmless. If a separate tool was sending that reply, repeating the whole task could send it twice. The distinction belongs in the workflow record. Anthropic’s API documentation says a streaming response can fail after an initial HTTP 200 success response. Seeing the first text appear, or receiving that initial status, does not establish that the full answer arrived. Require the integration to recognize completion and preserve partial work as partial. [Claude API error documentation](https://platform.claude.com/docs/en/api/errors) ## Give retries a limit and an owner A retry can clear a temporary failure. It can also prolong uncertainty if each layer repeats the same job independently. Ask the software supplier whether retries already happen inside its client library before adding another repeat button or automated loop. Anthropic documents two automatic retries by default for transient failures in its official SDKs, using increasing delays and honoring a retry-after instruction when present. Its error documentation also distinguishes temporary server problems from authentication, permission and malformed-request failures. Repeating the same request cannot be assumed to fix every category. [Claude’s documented retry behavior](https://platform.claude.com/docs/en/api/errors) For the service desk, the operational rule should specify when automatic attempts stop and who receives the case afterward. Preserve the request identifier for troubleshooting. Let staff see whether a job is waiting, being retried or awaiting a person, so they do not unknowingly launch competing attempts. AWS explains how an action can succeed even when its response never arrives. Its idempotent APIs use an explicit request identifier to recognize repeats and prevent additional side effects. The receiving service must enforce that contract; attaching an internal case number alone provides no such protection. [AWS on making retries safe](https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/) Ask specifically about the actions your workflow performs. Can a repeated attempt create another support ticket or send another email? Where duplicate prevention is unavailable, the plan needs a check of the destination record before another attempt. Retrying text generation and repeating an entire business process require different decisions. ## A backup model needs a narrower job description An alternative AI service can help keep work moving, but a second account is only the beginning of a fallback. The substitute needs the right instructions, approved reference material and permission to handle the data. It also needs capacity when the business calls on it. Choose a bounded fallback task before attempting a complete replacement. In our hypothetical desk, another model might classify routine messages while staff handle customer-facing replies. The team could evaluate it against representative cases, including ambiguous product names and requests that must go to a person. A fluent answer alone would not demonstrate that it followed the company’s support rules. Decide which information may be sent to the alternative service before an incident. Staff should not improvise by pasting customer records into personal accounts. Check the substitute’s data handling terms and access arrangements as part of procurement, alongside its output quality and price. Different model names also do not establish independent availability. A backup may still depend on the same login, network connection, document store or orchestration software. Map the dependencies your proposed alternative actually avoids. That exercise may reveal that a manual queue with accessible reference documents provides more useful protection than another model behind the same failing connection. Alternatives require maintenance as instructions change and product knowledge ages. Staff need practice with procedures they rarely use. A small business may reasonably preserve a slower manual service instead of paying to duplicate the entire operation. The choice should follow the cost of delayed work and the harm of an incorrect response. ## Resume with a reviewed queue Once the provider reports recovery, check a small sample of your own workflow before reopening normal processing. Include a case that exercises the document lookup and record update your business needs. A successful model response cannot establish that every connected system is ready. Then examine the waiting work. Remove cases already handled manually, inspect uncertain actions and identify requests whose circumstances have changed. A customer may have supplied new information during the interruption. Generating a reply from an earlier version of the case could create a fresh problem after the technical failure has ended. Release the remaining work in controlled batches. Keep capacity for new urgent requests, and watch whether the queue is shrinking. If incoming demand consumes all available processing capacity, the backlog will persist even when each new attempt succeeds. Catching up may require extra staffing, temporarily reduced service or an honest extension of response times. For a separate numerical example, suppose 24 cases arrive per hour and processing stops for 30 minutes. That leaves 12 waiting. If the desk then handles 36 per hour while 24 new cases keep arriving, it takes an hour to clear the backlog. These are illustrative assumptions, not measurements of the Claude incident. Google’s guidance on service-level objectives starts with the outcome that matters to users and the dependencies required to deliver it. For this desk, a useful measure could be the share of urgent cases receiving an appropriate response within the promised window. Provider availability is relevant, but the business also needs to know whether its customers received the service. [Google SRE: implementing service-level objectives](https://sre.google/workbook/implementing-slos/) Record the time normal customer service resumed, the number of unresolved cases and any corrections required afterward. Those measures expose recovery work that a provider’s status page cannot observe. ## Rehearse one interruption before expanding automation A short tabletop exercise can reveal missing access or ownership without disrupting live customers. Use a few fictional support cases and walk through this sequence: 1. Assume the model becomes unavailable halfway through preparing a response. Ask who activates reduced service and where staff find the original request. 2. Give one case a confirmed sent reply and another an uncertain send attempt. Check whether the team knows which system can establish the outcome. 3. Assume the provider has recovered while new cases continue arriving. Decide which work resumes first and how manually completed cases leave the backlog. 4. Have someone other than the plan’s author explain the procedure and identify the permissions or records they lack. Write down what the exercise could not answer. The resulting fixes may be modest: access to an existing queue, a clear pause control, a saved confirmation or an assigned recovery owner. None guarantees uninterrupted service. Each can make an interruption easier to contain without discarding the benefits of automation. Before giving an assistant another operational responsibility, ask a colleague to show how that responsibility would be handled during an outage. If the answer depends on the unavailable assistant remembering what it was doing, the continuity plan still has work to do. ## Sources - [Claude Status: Elevated errors for multiple models](https://status.claude.com/incidents/7g1qpkyz5gxh) — Provider's incident record gives an 80-minute impact window and a later resolved timestamp. The public JSON was independently read. It reports elevated errors, not universal failure, and contains no published root-cause account. - [Claude Platform: API errors](https://platform.claude.com/docs/en/api/errors) — Current documentation covers errors, default SDK retries and failures after a stream begins. These mechanisms do not establish completion of a business task or prevent duplicate actions in connected tools. - [AWS Builders' Library: Making retries safe with idempotent APIs](https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/) — Malcolm Featonby's explanation of uncertain responses and duplicate prevention. Its API contract must be implemented by the receiving service; an identifier alone is insufficient. - [Google SRE: Handling overload](https://sre.google/sre-book/handling-overload/) — Established engineering guidance on reduced functionality, priorities and bounded retries. The article adapts these principles to a hypothetical service desk; they do not diagnose the cause of Anthropic's incident. - [Google SRE Workbook: Implementing SLOs](https://sre.google/workbook/implementing-slos/) — Explains reliability objectives based on user outcomes and critical dependencies. The proposed customer-service measure and backlog example are illustrative applications, not observed results or a universal target.