When Microsoft 365 Goes Down, What Happens to Your AI Assistant?

An AI assistant can write a perfect follow-up and still leave your customer waiting. The email service it needs may be broken.

The Microsoft 365 disruption carried into November 13. And it shows why a working assistant is only part of the job. If it needs Outlook mail, a work calendar or connected files, trouble at Microsoft can leave it stuck.

If you run the business, what happens to that customer’s request while everyone waits? I would want the task saved, a clear rule for when to stop and someone who knows when to take over. “Try again later” leaves too much to memory.

What we know about this outage

Here’s the dated snapshot, not a live status feed. In its November 13, 2026 update at 10:56 a.m. Eastern, Microsoft said it was still working through the remaining effects of the outage. It was checking recovery across different ways of connecting and watching for stable service. Its public page still showed problems.[1]

Microsoft described problems with Exchange Online, its business email service. Those problems also affected Outlook mailbox access, calendar features and Copilot’s access to work email, calendars and files. But that did not mean every Microsoft service or every customer was down. Microsoft said much of Teams’ core calling and chat still worked, as did direct access to files in SharePoint Online.[2]

The trouble reached other companies’ AI tools too. A connector is the link an assistant uses to ask another service for information or an action. On November 12, Anthropic said a Microsoft 365 service incident was causing its connector’s mail, calendar and search tools to fail for most requests. Claude for Outlook was also affected. By its November 13 update at 10:40 a.m. Eastern, Anthropic was seeing signs of recovery in both. Some SharePoint search requests still returned errors. It was monitoring the recovery and warned that errors could return while Microsoft’s incident remained open.[3]

OpenAI was also investigating its Microsoft 365 connector incident, posted November 12 at 1:29 p.m. Eastern. It said new Microsoft connections might be broken and tools were not working as expected. Its notice did not give a final cause.[4]

As of this November 13 snapshot, Microsoft’s final root-cause report was still pending: it had not yet given its full account of what went wrong. Microsoft said it had no evidence of malicious activity tied to this incident and would share a full report once it had brought the problems under control. That was its statement at the time; a later investigation could find more. A separate security flaw is not evidence that it caused this outage.[5]

The assistant can be available while the job is blocked

Ask an assistant to follow up with a customer and several things have to work. The language model is the part that reads your instructions and writes. The connector asks the email or calendar service for records or actions. That service has to supply the records and carry out any action you have allowed.

So the model can help with wording while the connection cannot get the latest reply. Or the draft can be ready while the email service cannot tell you whether it sent the message. A working chat window proves very little about the rest of that job.

Think of a colleague who can write the message but cannot open the inbox. Giving them a better pen will not fix Outlook.

The model can have its own outage too. Check the company behind your assistant and the service it needs separately. Changing models may help if the model is down. But another model using the same broken Microsoft service can hit the same wall. Running a model on your own computer does not bring Microsoft’s inbox back either.

You can still get useful work from notes you already have, if your team allows the assistant to use them. It can sort those notes, write a draft or list what needs checking. But it needs to tell you what it could not check. Yesterday’s notes cannot prove a customer has not replied or a calendar slot is still free.

A follow-up that should stop halfway

Imagine you run a small event business. A sponsor asked for details, and you want your assistant to follow up before lunch. This is a hypothetical workflow to show the choices, not a report of a customer using a working cYpher.camp connection.

Normally, it would read the latest thread, check for a reply, review the package details you have approved and draft the next message. It could send only with the access, permission and checks your team has set up.

Now the inbox request fails. The assistant has yesterday’s notes, but it cannot see today’s reply.

It can draft a short message from those notes: “Thanks for your interest in the event. I’ll follow up with the details once I’ve checked your latest message.” It cannot honestly say, “You haven’t replied yet.” And it must leave prices, availability and meeting times unconfirmed until it checks a source your team has approved.

I would want the task to say: “Draft prepared from yesterday’s notes. Latest thread unavailable. Nothing sent. Task waiting for inbox access; owner to review before lunch.”

Save that with the task’s reference, due time, source notes, draft version and last attempt. Use a place your team allows and can open during the outage. Keep only what you need to pick up the work later. If the backup task list lives in the same unavailable service, you have made a backup-shaped decoration.

Now you can decide whether the message can wait. If it cannot, use an approved channel as your fallback: a backup way to contact the sponsor that your team has agreed to use. Name the person who takes over and use contact details your team has the right to hold. They should record the contact so the assistant does not follow up again later.

“Try again” needs a limit

Trying to read a message again is different from trying to send it again.

If the assistant is only reading, agree on how many times it can try again. For example: check after five minutes, once more after fifteen minutes, then stop and alert the owner. Those are example timings, not Microsoft’s instructions. Follow the service’s wait instructions, and have a person take over sooner if the customer’s deadline cannot wait.

Keep the paused task on the list. Record what failed, when it last checked, when it will check next and when a person takes over. Other jobs can keep moving if they have the current information and permission they need. I would not leave an assistant making endless requests and running up a bill because Outlook is down.

Sending is trickier. The email service can accept a message, meaning it has taken the message for sending, then fail to tell your assistant. The screen says error, but the message may already be on its way.

Mark the send “Unknown”: you do not know whether it went through. Check the original attempt, the email service’s available records and the mailbox’s sent items before deciding whether to send again. A missing record alone does not prove the send failed, especially while the service is still recovering.

Do not let the assistant send a new copy just because it got no answer. The same risk applies to meeting invites and changes to customer records.

Keep the steps separate: the draft is ready, you allowed the send, the assistant tried to send, the service accepted it, and delivery was confirmed. Accepting it for sending does not prove it reached the recipient. A message ID or an entry in sent items helps show what the service did; neither proves the customer read it.

If you still cannot tell what happened, leave the task on hold and ask a person to review it.

Ask whoever sets up your assistant to test these rules. Writing “avoid duplicates” in a prompt does not install duplicate protection. And a limit on retries does not stop an action already underway.

Your five-question backup-plan worksheet

Pick one job your team does often. Copy these questions into a document your team allows and can open when the service is down, or print them. Fill in real names and places now.

1. What services does this job need?

Job: ______ Assistant provider: ______ Needed email, calendar, file or customer systems: ______ Information that must be current: ______ Approved backup information and its last-checked date: ______

2. What stops if one service fails?

Blocked step: ______ Useful work allowed to continue: ______ Actions that must pause: ______ Read-only retry limit and wait times: ______ Customer deadline or earlier takeover time: ______

3. Where are unfinished tasks recorded?

Approved place you can open during an outage: ______ Task reference, owner and due time: ______ Last completed step and last attempt: ______ Draft version and approval status: ______ Any action with an unknown outcome: ______

4. How will we verify success?

For a draft, what must be checked? ______ For an action, which service record shows what happened? ______ What separate proof is needed for delivery or a booking? ______ Who checks whether someone already handled it? ______ What keeps an uncertain action from being repeated? ______

5. Who takes over, through which approved channel?

Named person and backup: ______ Working alert channel, tested without the failed service: ______ Permitted customer-contact channel and information: ______ What still needs the owner’s decision: ______ Who records the handoff and clears the task: ______

A filled-in first test

Start with a harmless practice job. This draft-only example uses made-up information. You can copy and adapt it, but it does not set up automation or give permission to contact anyone.

Job: prepare one sponsor follow-up draft. Trigger: the owner manually supplies this fictional note: “Sponsor A asked for event details yesterday. I cannot check whether they replied today.” No real names, addresses, attachments or customer records.

Services: an assistant that works and a notes file on your computer that your team allows you to use. This test needs no Microsoft connection. Treat the latest reply, current package details and availability as unknown.

Allowed work: write one short draft saying the details will follow, and list what the owner needs to check. No inbox access, sending, meeting invites, pricing promises, bookings or changes to customer records.

Task record: save the supplied note, draft and unknowns under practice reference SPONSOR-TEST-01 in the owner’s approved local file. Status: “Prepared, awaiting review. Nothing sent.” If the assistant cannot save there, the owner saves the output and checks that the file opens.

Completion check: compare the draft with the supplied note. It must not claim the sponsor has failed to reply or invent event details. The saved record must keep the unknowns and show that nothing was sent. Remove “yesterday” from the note and try again: the assistant should leave out that timing rather than make it up.

Retry and spending rule: one request within an existing allowance; no automatic retries, new paid tools or purchases. If you pay for each AI request, set a spending cap the system can enforce before testing. Writing a limit here will not stop a bill.

Human fallback: the owner writes the draft if the assistant is down. For this practice run, review happens in person and no customer is contacted. Before using it for real work, name the backup person and agree on where to keep the data and how to contact people. Test the actual access and sending controls.

Recovery starts with checking what happened

A better status page is a reason to check, not restart everything at once. Test the connection by reading something harmless, then go through the waiting tasks. Did the sponsor reply? Did a colleague handle it? Which deadlines changed? Check whether any earlier actions still have an unknown outcome.

Find out what happened to unknown sends before trying again. Use fresh records to update old drafts. Permission to send one draft to one person does not cover a changed offer or meeting time; that may need a new decision. Restart a few tasks and check the results before letting the rest run.

An outage does not cancel your privacy rules. Do not paste customer mail into a new AI service, forward it to a personal account or remove access controls just to get moving. Your team must approve any backup service or contact method for that information. A person taking over still needs permission to access it.

Once things work again, look at what pulled you away from other work. Which checks could the assistant handle under rules you agree on and test? It can take on routine read checks and pause alerts after testing. Price changes, unclear sends and new promises to customers still need the right person to decide.

Pick one customer job and fill in the worksheet while everything works. Then practice a missing inbox and a missing assistant separately. I would want the next outage to leave me with a short list of decisions, not a guessing game about who was contacted and what still needs doing.