Ship an Outlook-Resilient AI Agent: Detect Failures, Preserve Context, and Fail Over to Alternate Channels
Microsoft attributed the outage to a core authentication configuration issue and warned recovery would be gradual; agents need detection, state preservation, and fallback routing.

Microsoft 365 degradation hit Exchange Online Monday afternoon. Microsoft blamed a core authentication configuration issue and said recovery would be gradual. Operators: instrument Graph calls, persist state, and route fallbacks.
Downdetector tracked thousands of user reports of Outlook problems during the incident. Microsoft's status page reported service degradation for Microsoft 365 Business or Enterprise. Microsoft warned recovery would be gradual and that downstream scenarios, including search, could remain impacted. Shared error messages suggested an expired internal certificate, though that was framed as a possible explanation.
Five-step outage readiness checklist
Test the failure path before an incident. It prevents corrupted conversations, duplicate sends, conflicting meetings, and escalations without state.
- Detect API and authentication failures early. Instrument every Microsoft 365 call. Log endpoint, tenant, app registration, HTTP status, retry count, latency, and error code. Treat 401 and 403 as authentication or permission failures. Treat 429 as throttling. Treat 5xx as service degradation. Use a circuit breaker after repeated failures. Alert on rising error rates, not single bad requests. Monitor send, read, search, and calendar operations separately.
- Classify severity before acting. Map a single 401 to token refresh. Map repeated 401s across tenants or app registrations to authentication configuration. Map a 5xx spike on Exchange Online to service degradation. Map search failures to downstream impact. Assign low, medium, or high severity. Use severity to pause, degrade, or fail over.
- Preserve conversation and task context. Persist state before stopping autonomous actions. Store current task, messages read, draft composed, calendar items checked, intended recipients, and last successful step. Use a durable store outside the agent process. If Microsoft 365 writes fail, write to an internal database, queue, or object store. Include timestamp and reason code. Prevent reprocessing. Give operators a clean handoff.
- Route to fallback channels. If email is unavailable, move to an available alternate channel. Use internal ticketing, a status page, an operations webhook, a secure human message, or a delayed retry queue. Carry preserved context. Do not ask customers to repeat information. If fallback is degraded, stop and create a minimal incident record.
- Verify recovery before resuming autonomous actions. Do not resume on a single successful call. Run a recovery probe. Confirm authentication, mailbox read, search, send, and calendar operations. Check for delayed effects. Resume only when the probe passes and error rate is stable. Replay queued actions in order with idempotency keys.
Design the fallback like a production system
Use idempotency keys, transaction logs, dead-letter queues, and approval gates for fallback sends and calendar changes. Log state transitions. Queue non-retryable actions. Gate high-risk actions, such as external sends, contract-related messages, or calendar changes affecting multiple people.
For Microsoft 365 email and calendar agents, the minimum viable failure path includes a health endpoint, an error taxonomy, a state store, a fallback queue, and a recovery probe. Report last successful call, current error rate, and circuit-breaker state from the health endpoint. Map common failures to operator actions in the error taxonomy. Store state outside the process. Preserve queue order. Probe the same operations the agent uses in production.
Test the failure path. Simulate expired tokens, permission denials, throttling, and service degradation. Simulate a search failure after a partial read. Simulate a send failure after a draft is created. Verify that the agent pauses, preserves context, routes to the fallback, and resumes cleanly. Run the test repeatably in a non-production tenant or sandbox with realistic data.
Stop condition: no autonomous sends or calendar changes until the recovery probe passes and error rates are stable.