LearnMicrosoft Teams › 13 · Architecture & advanced operations

Resilience and outage playbooks

You cannot fail over Teams — Microsoft owns the service. What you CAN own: knowing which dependency died, what still works during each outage class, and executing comms through a channel that isn't the thing that's down.

Outage classes and what survives them

Class Signature Still works
Teams service (regional/global) Sign-ins fail/service health advisory PSTN via SBA branches (voice module); email; your status page
A dependency (EXO, SPO) Teams up, one limb dead (no calendar / Files spin) — the constellation signature Chat, calls; teach the desk this pattern so 'Teams is down' tickets get routed right
Auth (Entra) Nothing signs in ANYWHERE Already-signed-in sessions coast on tokens for a while — do NOT push reauth (no CA changes, no revocations) during the window
Your network/egress Only your sites affected; hotspot works Split-tunnel remote users; the class where the fix IS yours
Your config (self-inflicted) Correlates to a change; drift log shows it Rollback — serv365's before/after IS the rollback spec

First-five-minutes triage: service health (admin center/API — our scan's service-health leg) -> Entra sign-in errors -> your egress checks -> the drift log for the last 24h. The order matters: it walks blast-radius from theirs to yours.

The playbook to have written down

  • Comms channel that isn't Teams: status page, SMS tree, email list — decided, tested, and the FIRST move ('we know, updates at X') because ticket floods bury triage.
  • Degraded-mode cards: per outage class, one card: what works, what doesn't, user guidance (e.g. EXO-down: 'meetings via links still join; calendars blind'). Pre-written beats composed-at-2am.
  • The do-not list for auth outages: no policy pushes, no cert rotations, no 'quick fixes' that add variables mid-incident.
  • Post-incident: your OWN timeline (when did YOUR users feel it — CQD/ sign-in data) vs Microsoft's PIR; gaps feed your monitoring backlog.

What to watch (proofs)

  • Advisory latency: when service health posted vs when your users felt it (ticket timestamps) — if users beat the advisory consistently, your own canaries (a scheduled test call/join probe) earn their keep.
  • Token-coast behaviour: during any auth blip, sign-in failures vs active-session continuity in the logs — evidence for the do-not-touch rule.
  • SBA reality: the voice module's failover test cadence — an untested survival mode is a slideware control.
  • Comms drill: one tabletop per half-year — time from 'incident declared' to first user-visible message on the non-Teams channel; minutes, not aspirations.

PowerShell for this concept

Discussion

No messages yet — start the thread.

Sign in with your email to join the discussion — we send a one-time link, no password.