What this usually means
A symptom identifies a failed operation, not its cause. The failure might sit in your client, network, identity path, mailbox service or downstream delivery. Reports from other people make a shared dependency more plausible; they do not prove your account is affected by the same incident. Start with scope and timing, then change one variable at a time.
The first ten minutes — establish facts before touching code.
- 1Write down the failed action, its first observed time and timezone, affected account type, and exact error text.
- 2Preserve unsent text in an approved location before closing a window or attempting another client.
- 3Check official service information; ask an authorised administrator to check the tenant-specific Service health view.
- 4If permitted, compare one small action in an already available web or desktop client. Record the difference.
- 5Ask whether another affected person has the same operation failing at the same time; avoid a mass test.
The specific files, logs, configs, and dashboards that usually own this bug.
- searchMicrosoft 365 admin centre: Health, then Service health, including the issue scope and update timestamp.
- searchOutlook connection or sync messages, the Outbox, and the time of the last successful refresh.
- searchExchange message trace for a particular delivery question, accessed by an administrator with appropriate permissions.
Practical causes, not theory. These are the things you will actually find.
- warningA shared service dependency or regional path is degraded; confirmation requires relevant official evidence.
- warningA client-specific sync, profile or add-in problem affects one application while another still works.
- warningA local network, proxy or identity-policy issue affects a narrower group than the service incident.
Concrete fix directions. Pick the one that matches your root cause.
- buildFor a matching confirmed service issue, preserve evidence and follow the published mitigation instead of changing unrelated account settings.
- buildFor a client-only failure, use your organisation’s supported diagnostic path and make reversible changes one at a time.
- buildUse an approved alternative communication channel for urgent coordination, while avoiding repeated copies of the same message.
- buildIf no matching incident appears, report the observed issue with timestamps, affected operations and a representative error.
A fix you cannot prove is a guess. Close the loop.
- verifiedRepeat one low-impact operation that previously failed, then check that the expected state appears in the other relevant client.
- verifiedFor email, distinguish successful submission from delivery; check a controlled recipient and, when necessary, message trace.
- verifiedObserve more than one successful attempt over time before concluding that an intermittent symptom has cleared.
Things that make this bug worse or harder to find.
- warningDo not mass-reset passwords, remove accounts or uninstall Outlook just because a shared service may be degraded.
- warningDo not disable multifactor authentication, certificate checks or security controls to work around a connection error.
- warningDo not repeatedly click Send or recreate calendar invitations without checking the original operation’s state.
Compare four boundaries: one account versus several, one client versus another, one network versus another approved network, and reading versus sending. You do not need to test every combination. Choose the smallest comparison that could distinguish your leading explanations. A desktop failure with a working web session narrows the investigation; it does not automatically prove a corrupt profile.
Calendar visibility deserves its own row. Being able to read cached events does not prove new meeting updates are syncing, and a locally saved appointment is not evidence that invitees received an update. Use an innocuous test only when your organisation permits it. Record what changed remotely rather than relying on a reassuring local icon.
A public status update gives broad incident context. The tenant Service health view is more useful for determining whether Microsoft has identified an issue relevant to your organisation. Read the described user impact and affected functions, not just the headline. Keep the update timestamp with your notes so an old screenshot does not become a current claim.
An improving status does not prove every operation works for every user. Conversely, an empty dashboard does not establish that a local symptom is imaginary. Tenant visibility, investigation timing and scope can differ. An administrator can report an unlisted issue through the supported health workflow. Continue collecting narrow observations without inventing a service-wide explanation.
A useful handoff contains the operation, timezone-aware timestamp, client version, scope comparison and any displayed correlation identifier. Redact message bodies, recipient lists and authentication material before sharing it outside the authorised support path. A screenshot of an error is more useful than a whole mailbox screenshot containing unrelated information.
For the developer side, read the Graph retry guide linked below. For messages that were accepted but remain missing, use the email recovery guide. Buglyst’s outage debugging hub also offers a no-signup pagination starter: it practises following an HTTP boundary in a simulation, not diagnosing a live Microsoft tenant.
Related debugging guides
Frequently asked questions
Should I sign out and sign back in during a suspected outage?
Preserve your current session and unsent work unless the official mitigation or your support team specifically requires reauthentication. An existing session can remain useful while a new sign-in attempt encounters another failing dependency.
Does a working Outlook web session rule out a Microsoft 365 issue?
No. Different clients can reach different operations, cached states and service paths. Treat the comparison as evidence about scope rather than a complete diagnosis.