A Microsoft 365 Outage Takes Your Agent's Tools With It

On November 12, 2026, Microsoft 365 failed broadly enough that Outlook, Teams, SharePoint, Exchange, and Copilot were in the same incident, and the failure did not stop at Microsoft's own apps. OpenAI posted that its Microsoft connectors were broken: new connections might not complete, and tools were not behaving. Anthropic posted the same shape for Claude. Mail, calendar, search, and Claude for Outlook failed because an upstream provider failed. The Claude API stayed up. People watching a status page that said the model was operational still had an assistant that could not read the inbox it had been allowed to read.

That split is the lesson for anyone who has wired an agent to Graph, Outlook, SharePoint, or Teams. The product you pay for inference is not the product that holds the customer's mail. When the second product stops, your agent does not become a chatbot with fewer features. It becomes a process that calls a dead tool, retries, and writes a confident paragraph about data it did not fetch. What you do when your own deploy fails is a different afternoon, covered in recovering an AI-built app after a failed deploy. The invoice from a retry loop is covered in what agent retries cost. This note is the vendor under the tool.

What actually failed

Microsoft's service health updates through November 12 and 13 covered the suite people mean when they say "365": Outlook and Exchange, SharePoint and OneDrive, Teams, Planner, the admin centers, and Copilot. Coverage from IT Pro and Mint described Copilot Chat failing to load and workplace data failing to come back with it. Microsoft's public explanation, including a statement from the EVP responsible for Copilot and agents, was that a large number of servers became unexpectedly unavailable and the remaining ones took the load. The company said it did not have an indication this was a cyberattack, and that the load was not an excess of traffic that would suggest a denial of service. Later updates described an authentication and routing configuration patch applied to part of the infrastructure, with no promise of a full restore time while the rollout continued.

Downdetector's Outlook reports climbed past 130,000 during the incident. That number is user complaints, not a count of API errors, but it is enough to throw out the idea that this was one region and a status page being slow to update. Government mail, a school administration platform in New South Wales, and at least one company that moved an earnings announcement were in the reporting. Your agent does not get a quieter Graph because the outage made the newspaper.

The AI vendors' status pages are the cleaner artifact, because they name the component. OpenAI's incident, elevated errors affecting the Microsoft 365 connector, said new connections may be broken and tools were not working as expected. The affected component was connectors and apps, not the model API. Anthropic's timeline, as reported from their status page, started at 17:52 UTC on November 12 with errors and slow responses on mail, SharePoint, Teams chat, and calendar through the connector. By 18:34 UTC they called it an upstream provider. Mail, calendar, and search were failing for most requests. Claude for Outlook followed: mail and calendar actions might fail, and some people could not open the add-in. At 22:23 UTC they said the cause was a Microsoft 365 service incident and pointed people at Microsoft's status page. claude.ai and Cowork showed degradation. The API, Claude Code, and the console were listed as operational.

Read those two status pages as an architecture diagram. The assistant's brain was fine. The hands it uses on Microsoft data were not. A product that hides the tool call inside a single "ask Claude" button will report a vague failure, or, worse, a normal-looking answer. A product that surfaces "the Outlook tool failed" can stop. Most generated apps do the first.

The agent does not inherit Microsoft's status page

Your user is not watching Microsoft 365 service health. They are watching your app. If your app's only signal is the model provider's green check, you will tell them nothing is wrong while every mail tool times out. Anthropic did the honest thing on their own status page by separating the API from the connector. You have to separate them in the product, because your user will not.

List the calls. A workflow that searches a mailbox, reads a SharePoint document, posts to Teams, or creates a calendar event is a Microsoft dependency even when the prompt never says Microsoft. The SDK might say "connector," "Graph," or the name of a tool the agent picked. Write the list down when the integration is added, not during the outage. The list from this incident is a decent seed: mail, calendar, search, SharePoint, Teams chat, the Outlook add-in, Copilot's access to workplace data. If your agent does any of those, it was down, regardless of what your model host reported.

Copilot being down is the case where the agent is Microsoft's. You cannot patch that. You can notice that a process you chained off Copilot Studio or a Graph subscription has stopped, and you can stop promising a result. A queue of your own, with the work item still in it, is a better state than a spinner. The work item can run when Graph answers again. A spinner that retries forever spends money and then fails the same way.

There is a second-order dependency that is easy to miss. Your login might be Entra ID. Your files might be OneDrive even when the model is not Microsoft. An outage that includes authentication and routing, which is how Microsoft described the patch they were rolling, can fail the sign-in before it fails the clever tool. If users cannot sign in, the agent is not degraded. The front door is shut. Have a status that says so, and do not send those attempts to the model to "try anyway."

What the code should do when the tool is dead

Fail closed on that step. If the tool returns a timeout, a 429, a 503, or a connector error from the provider, the turn ends with a named failure. The user sees that mail could not be read. The model is not asked to continue the task without the mail and then speak as if it had read it. Continuing is how you get an answer that invents a thread.

Do not retry inside the agent loop. A model that sees an error and decides to call the same tool again is a retry policy you did not configure. Put the retry in one place, outside the model, with a limit and a backoff, and only for errors you have marked as worth retrying. During this outage the upstream was down for hours. Ten retries a minute for three hours is not resilience. It is a bill and a log line. The token math of that loop is the same math as any other runaway agent: each attempt resends the context. Cap the turn. If you do not have a cap, the outage is when you find the invoice, which is the situation the token-cost note is about.

Queue the work if the task can wait. "Summarize this mailbox every morning" can wait. "Is this invoice overdue, right now, in front of a customer" cannot, and should fail visibly. Those are different products. Generated apps often use one loop for both. Split them. A background job with a dead-letter queue after N failures is boring, and it is the right shape for mail. An interactive turn should stop on the first hard failure from Graph and say which tool failed.

Idempotency matters more when the tool comes back. A create-event call that timed out may have succeeded. The retry that "fixes" the morning's outage can create a second meeting. Store the idempotency key you sent. Treat "timeout" as unknown, not as failure, for any tool that writes. Reads can be retried. Writes need a lookup first. This outage involved calendar writes. The duplicate is the bug you will see on the way back up, after the status page is green and your queue drains.

Degrade the features that are Microsoft and leave the rest up, if you actually can. Anthropic's split between the API and the connector is the model. Your app can still answer from data you store yourself while SharePoint is unreachable. It cannot answer from SharePoint. Hide the buttons that call the dead tool. Leaving them enabled so the model can "try" is how the retry loop starts from the UI instead of from the agent.

What to notice in the logs while it is happening

You will not get a push from Microsoft to your app. You will get a change in error rate on one tool name. If you do not log the tool name, you will see "the agent got worse" and spend the incident raising the model timeout. Log the tool, the status code or connector error, and whether the turn stopped or continued. A turn that continued after a mail failure is the bug. A turn that stopped is the design.

Watch the count of calls, not only the count of errors. A retry storm is a rise in attempts with the same error. Alert on attempts per task. An alert on "any Graph error" will fire for one user's bad token and train you to ignore it. An alert on "mail tool attempts per successful task crossed a line" is the outage.

Keep a human status that you write, separate from the vendor's. "Microsoft 365 tools are failing, started 17:52 UTC, we have stopped retries" is a sentence your support channel can paste. Linking only to Microsoft's status page pushes the explanation onto a page your customer may not be allowed to open. You can link it as the upstream source. You still own the sentence about your product.

When the vendor says they are rolling a patch through regions, expect a partial recovery. Some tenants will work. Yours might not. A global boolean "Microsoft is up" set by the first successful call will hide the tenants that are still failing. Key the circuit breaker by tool, and if you are multi-tenant, do not let one tenant's success close the breaker for everyone unless you have checked more than one.

After the incident, read the queue depth and the dead letters. The work that did not run is the backlog you owe. The work that ran twice is the cleanup. A calendar full of duplicate events is a worse outcome than a morning with no summary. Prefer the quiet failure.

What this is not

It is not a reason to host your own model so that mail cannot fail. The model was the part that stayed up. Moving inference does not move Exchange. It is not a reason to give the agent a browser and tell it to use Outlook on the web. A browser pointed at a service that is down fails too, and it fails with the user's session, which is the problem in browser agents. It is not a security incident unless Microsoft says it is. They said they had no indication of malicious activity. You still rotate nothing on a rumor, and you still stop the retries.

It is a reason to know your upstreams. A generated app accumulates connectors because each one was a prompt: "also read my email," "also check SharePoint." Each prompt added a company that can halt that feature. Write them down. For each one, name the status page, the tool names in your logs, and the behavior when the call fails. If the behavior is "the model will figure it out," you have the behavior this outage punished.

A dependency you can postpone is different from a dependency in the request path. Morning digests wait. A checkout that waits on a SharePoint permissions lookup does not. If a payment flow calls Graph, you have coupled revenue to a collaboration suite. That is the coupling to remove when you are back, not during the incident. During the incident you fail the lookup visibly and decide whether the sale can proceed without it. Decide that now, in the code, so the on-call is not the person who invents the policy.

Write the decision next to the tool, not in a wiki. A one-line comment in the client that calls Graph, naming the behavior on timeout, survives the next agent edit better than a Notion page nobody opens. If an agent regenerates the client, the test is what keeps the behavior: a stubbed 503 from the connector must not produce a second model call. That test is the outage, rehearsed. Run it when you add the tool. An incident is a bad time to learn that the generated retry helper wraps the connector and the model both.

What to check before the next workday starts this way

1. List every tool that calls Graph, Outlook, SharePoint, Teams, or Copilot. If you cannot list them, turn on tool-name logging before you do anything else.
2. For each tool, write the failure behavior: stop the turn, queue, or continue. "Continue" is only acceptable for a step the user was told would be skipped.
3. Put a cap on retries outside the model. One interactive attempt. Background retries with backoff and a dead letter. No loop inside the prompt.
4. Treat timeouts on writes as unknown. Look up the object before you create it again.
5. Separate your status from the model host's status. The API being green did not mean the connector was green on November 12.
6. Alert on tool attempts per task, not on a single error.
7. If a flow that takes money or signs a user in depends on Microsoft 365, say so in the runbook. The outage is not the week to discover the coupling.

If you cannot say what your app did during this outage, you do not yet have a connector design. You have a prompt that worked until Microsoft stopped answering.

How Techtribe makes an agent fail closed when a tool is down

We read the tool list and the logs from a failure, and we name which calls retry, which calls invent an answer, and which calls stop. You get a cap and a queue where the work can wait, wired so the model is not the retry policy. We do not raise the timeout and call the outage handled.

If the product has no timeout, no tool log, and no queue, that monitoring belongs in a Production MVP. A single connector with a known error can be a smaller scope. The scope call is 30 minutes with a founder, and it is where we say which you are in.

Bring the tool list and what the app did during this outage, including any retry storm on the invoice. If you do not have the logs, the first deliverable is the tool name on each call.

The fixed scope for taking a generated app to production is a page per tool: Lovable, Bolt, v0, and Replit.