One person with this dialog has a PC problem. Twenty people with this dialog at 10 in the morning have a server story. This page is for that pattern: what is happening on the Exchange side, what the administrator checks, and what you can usefully report instead of reinstalling Outlook on twenty machines.
The honest dividing line is pattern. A stall that follows one user, one PC or one message is local. A stall that arrives for a whole team at the same hour lives where the mail lives. Exchange and Microsoft 365 deliberately throttle connections to protect the service, mailboxes grow into sizes that make every request heavier, and autodiscover or certificate faults make clients queue politely at a door that is not answering. None of those is fixed from a user's desk — but users who report well get them fixed days sooner.
Exchange and Microsoft 365 limit how much work one mailbox or one application may demand, so a single runaway client cannot slow everyone. When a mailbox crosses those limits — a huge sync, a misbehaving phone app, a giant shared mailbox — the server answers more and more slowly, and Outlook shows its waiting dialog. From the user's chair it feels random. From the admin's chair it is a policy doing its job, and the fix is finding what is over-working the mailbox, not touching the PC.
A mailbox with tens of gigabytes and folders holding tens of thousands of items makes even simple requests expensive: opening the folder, searching, syncing. The dialog then appears on big folders and vanishes on small ones — a pattern worth reporting exactly. The durable cures are admin-and-user teamwork: archiving old mail, keeping single folders to reasonable sizes, and using the Cached Exchange Mode slider so everyday work uses a local copy instead of a server round trip.
Before Outlook can ask for mail it must find and trust the server, through Autodiscover and a valid certificate. When that layer breaks — an expired certificate, a changed DNS record after a migration — every client stalls or repeatedly asks for credentials at once. Users cannot repair this, but they can spot it: a whole office failing together right after a mail migration or a certificate date is a giant clue, and saying so in the report saves the admin an hour.
Open your mailbox in a browser (Outlook on the web) and do the same work. If webmail is instant while Outlook stalls, the mailbox and server core are healthy and the slowness sits in the desktop connection path — client settings, autodiscover, or the network route. If webmail crawls too, the service itself is loaded and the only user-side fix is patience. This one test, included in your report, tells the admin which half of the system to open first.
A useful report has four lines: when it started, who is affected, what pattern you see (which folders, which actions), and the webmail result. "Outlook is slow" starts an investigation from zero; "since 10:05, twelve people, stalls opening the shared Accounts mailbox, webmail instant" nearly finishes it. Screenshots of the dialog add nothing — the dialog is identical in every cause. Times and patterns are the evidence.
Do not rebuild profiles on twenty PCs, do not delete OST files across the office, and do not turn off Cached Exchange Mode to "connect directly" — during a server event those actions multiply the server's load with fresh full syncs and can turn a slow hour into a broken day. The disciplined move is boring: confirm the pattern, report it well, use webmail, and let the server side be fixed once, centrally.
The video shows how to recognise the whole-office pattern and run the webmail comparison, so you can tell a server event from a PC fault on sight.
Watch Full VideoYes. Throttling is per mailbox and per application as well as service-wide. One mailbox that syncs excessively — often an old phone app retrying forever — can be slowed deliberately while neighbours stay fast. The pattern is one user, every device, which points away from any single PC.
Almost never. Migrations change autodiscover records, certificates and mailbox locations at once, and clients feel each change as connection stalls. Report the timing prominently; it directs the admin straight to the migration changes.
Webmail is the perfect stand-in during a server event and a fine choice for some users. But the desktop stall still deserves a fix, because the same server-side weight usually grows. Use webmail to keep working, not to bury the report.