Keep deadline work moving during an AI outage by checking accessible evidence, choosing a safe manual minimum and protecting review time before switching services.
Direct answer: Stop repeated retries long enough to identify the work still required, the evidence you can access and the smallest acceptable deliverable you can complete safely. Assign a decision owner, protect time for review and use an approved manual fallback before considering another provider. If essential evidence or authorised review is unavailable, renegotiate the deadline or scope rather than sending unverified work or uploading confidential material to an unapproved service.
The urgent problem is not necessarily restoring the AI tool. It is meeting an obligation with trustworthy work. An outage can expose that the team stored its only source notes in a chat, but changing providers will not automatically recover those notes.
I recommend delivering a narrower verified result over rushing into a new service on deadline day. Switching can be sensible when an approved alternative and a rehearsed process already exist, but an unfamiliar account is not a ready-made continuity plan.
Applies to: small-team deadline work during an apparent service failure. This article does not diagnose a current provider outage or assume that unavailability means a cyber attack.
Use the deadline continuity sequence
The deadline continuity sequence is an editorial method for preserving the work that matters while an AI dependency is unavailable. It moves from situation, to usable evidence, to a minimum deliverable and an explicit decision.
Name one person to coordinate the response. Others can investigate or continue independent tasks, but avoid several people making conflicting promises to the client or changing tools separately. Record what is known and when it was checked.
Set a brief diagnostic window proportional to the remaining time. A simple account issue may be resolved quickly, but do not let repeated speculative fixes consume the whole delivery period. The working limit should be chosen by the team, not presented as a universal outage standard.
The guide to AI adoption without losing trust emphasises clear ownership and the ability to stop. On deadline day, ownership includes deciding when to leave the unavailable workflow and use another authorised way to finish.
Establish what is unavailable without making destructive changes
Check the exact symptom: can you sign in, open existing material, submit a new request or export a result? Record the error wording and time without exposing private prompts or credentials in a public support post.
Use the provider's verified status and support pages, and ask another authorised colleague whether their access is affected. A status page can inform the diagnosis, but the absence of an incident notice is not proof that your particular account is working.
Do not clear local data, delete conversations, reinstall applications or change security settings as random first steps. Such actions can remove useful evidence or working state. Preserve accessible drafts and source documents through approved methods before attempting any change that could affect them.
If there are signs of a security incident rather than ordinary unavailability, follow your organisation's incident process and obtain authorised technical help. NCSC guidance for disruptive cyber incidents recommends establishing the operational state, decision authority and a central record. Its context is cyber response, not a claim that every AI outage needs that level of intervention. NCSC immediate-activities guidance.
List the evidence that still exists outside the tool
Open the original brief, source documents, approved figures and latest saved draft. Mark each required part as available, missing or not yet verified. Do not reconstruct important facts from memory just because a previous AI answer probably contained them.
Separate lost convenience from lost evidence. If you have the source material but not the generated summary, manual work may be straightforward. If the only record of a critical claim was a chat response, you may need to recover the original source or remove that claim.
Identify tasks that do not depend on the service: checking quotations, reconciling numbers, preparing a document layout or confirming the recipient's requirements. Assign only work people are authorised and competent to do.
Do not recreate missing access by sharing somebody else's credentials. An authorised colleague can provide an approved source or export through the normal process, but account sharing can introduce a separate security and accountability problem under pressure.
Define the minimum acceptable deliverable
Write what the recipient genuinely needs by the deadline. Distinguish essential findings from optional polish, supplementary examples or a longer narrative. A shorter report with verified answers may satisfy the task, but only the responsible person can approve a material scope change.
Keep quality requirements intact. “Minimum” does not mean skipping evidence checks, omitting necessary risk information or disguising an unfinished draft as final. It means reducing non-essential scope while preserving the purpose and reliability of what remains.
If the original commitment cannot be met, communicate early with a concrete alternative: what can be delivered, what will be missing and when the rest can follow. Do not promise a recovery time that the provider has not established or that your own process cannot support.
Keep the review owner and review window explicit. A fallback that fills every remaining minute with production but leaves none for checking is not a credible completion plan.
Compare a four-hour fallback with a rushed migration
Imagine a fictional team with four hours, or 4 × 60 = 240 minutes, before delivery. It allocates 35 minutes to diagnosis, evidence inventory and the scope decision. That leaves 240 minus 35 = 205 minutes.
Assume the manual minimum requires 120 minutes of production, 45 minutes of review and 15 minutes to package and communicate the result. Total remaining work is 120 + 45 + 15 = 180 minutes, leaving 205 minus 180 = 25 minutes for a small interruption or correction.
Now consider an unfamiliar-provider route. Suppose account and permission checks take 40 minutes, adapting inputs takes 30, generation takes 25, review takes 45 and packaging takes 15. That totals 40 + 30 + 25 + 45 + 15 = 155 minutes, apparently 25 minutes faster than manual work.
But assume the team has not established the provider's suitability and needs a further 60-minute approval and data-handling review. The route becomes 155 + 60 = 215 minutes, exceeding the 205 minutes available by ten. If approval cannot actually be obtained, the route is unavailable, not merely slower.
All durations are illustrative assumptions, not measured migration times. The point is to include the steps an emergency comparison tends to omit. A pre-approved alternative with prepared inputs could change the decision; an unapproved upload cannot be made acceptable by excluding its approval cost.
Continue in checkpoints, not constant retries
Once the fallback is selected, let the production team work. Assign one person to check service recovery at agreed intervals if that information could still change the plan. Avoid interrupting everyone with repeated unchanged status updates.
If the tool returns, decide whether rejoining it would help the remaining work. Do not discard a nearly completed verified manual draft simply because the familiar interface is available again. Recovery of the service is not an instruction to restart the task.
Keep a short record of manual assumptions and unresolved items so the final reviewer can inspect them. If a source remains unavailable, state the limitation in the deliverable or remove the unsupported claim according to the agreed scope.
After delivery, review the dependency that caused the problem. Keep critical evidence, accepted decisions and final outputs accessible outside a single conversation where the team's policies permit. Test the fallback before the next urgent deadline rather than buying a second subscription without a defined purpose.
Act within the next half-hour
- Preserve accessible work and appoint the person who can decide scope and communicate changes.
- Check the symptom and official status once, then inventory the sources and unfinished tasks.
- Calculate a manual minimum that includes review and delivery time. Compare only alternatives that are already approved or can genuinely be approved in time.
- Commit to the feasible route, communicate any changed scope and set a point at which unresolved evidence means delaying or withholding the affected work.
Stop troubleshooting when it threatens the verified fallback's review window. Stop delivery if the remaining work cannot meet essential accuracy or permission requirements. A missed or renegotiated deadline is preferable to a false claim that unverified work is complete.
Related guides
Frequently asked questions
Should everyone keep trying the service in case it comes back?
No. Assign one person to monitor recovery if it could still change the plan, while others continue authorised independent work. Repeated retries can consume attention without creating evidence or deliverables. Agree when the next check matters and what result would justify switching back. If the fallback is nearly complete, restored access may not improve the outcome. Do not let the team repeatedly abandon productive work because one person briefly sees a successful response. Confirm usable recovery for the relevant task before changing the plan, and preserve the work already completed.
Can we use a colleague's personal AI account temporarily?
Only if the organisation explicitly permits that account and service for the material and the intended use. A deadline does not remove data-handling, contractual or access requirements. Do not share credentials or assume a personal plan has the same terms as the approved team account. If a generic task can be completed with dummy or public information, assess that limited route separately. For confidential work, use the approved manual fallback or communicate a delay when permission is missing. An available login is not the same as an authorised continuity option.
What if all our source notes are inside the unavailable conversation?
Treat that as missing evidence and identify which claims can be reconstructed from original documents or other approved records. Do not substitute memory of the AI answer for the source. If a critical fact cannot be verified in time, remove it, qualify the deliverable or renegotiate the deadline. Preserve any accessible exports without making destructive changes. After the immediate task, change the workflow so accepted evidence and decisions are stored in an appropriate shared record outside the single conversation. The goal is recoverable work, not simply a backup copy of every speculative message.
Should we tell the client that the AI tool is down?
Communicate the effect on the work and the concrete alternative, following your contractual and organisational disclosure requirements. The client usually needs to know what will arrive, when and with what limitations, rather than receive an extended account of internal troubleshooting. Do not use the outage as an excuse for an unsupported promise or imply that the provider has guaranteed a recovery time when it has not. If AI use is materially relevant to the engagement, be honest about it. Keep one authorised person responsible for the update so messages remain consistent.
Is buying a second AI subscription a sensible backup?
Only if a defined fallback task justifies it and the alternative is approved, maintained and tested. A second account that nobody knows how to use with the required files may offer little practical continuity. Compare it with keeping source material accessible and maintaining a manual method. If both services depend on the same unavailable account system or data location, the apparent redundancy may not address the actual failure. Identify the dependency you need to reduce before spending money, then test whether the proposed backup can produce a checked deliverable under realistic constraints.
When should we stop trying to meet the original deadline?
Stop claiming the original commitment is feasible when the remaining time cannot cover essential production, evidence checking and authorised approval. Make that calculation explicitly and communicate a revised option before the last minute where possible. Do not remove necessary review merely to preserve an optimistic schedule. A smaller agreed deliverable may still be useful, but it must not conceal missing evidence or changed scope. For consequential work, the responsible owner should decide what must be withheld or delayed. The stopping condition is a quality and authority boundary, not simply frustration with the unavailable tool.
Sources and verification
- NCSC: immediate activities during a disruptive cyber incident, checked 11 September 2026 for the limited operational-state, ownership and recording principles cited. An ordinary AI outage is not assumed to be a cyber attack.
- The parent was read in local publication files after its public URL could not be retrieved. Supplied internal paths are retained without independently confirming live publication. The deadline sequence and all timings are illustrative editorial work.
This article is practical guidance. Apply it in proportion to your tools, evidence, risks, and responsibilities.
