On June 17, a routine traffic-routing change inside Microsoft Teams went sideways, causing a widespread presence outage that showed active users as Away or Offline across Europe and beyond. The incident, tracked under advisory TM1394359, primarily affected the EMEA region, but users in other regions also saw incorrect statuses when they interacted with anyone in the fault zone. While the outage didn't take down chat or meetings, it exposed just how deeply organizations rely on that little green dot — and how costly a reflexive "reinstall Teams" reaction can be.

What Actually Happened on June 17

Microsoft confirmed that a recent Teams traffic-routing change was responsible for the disruption, which caused presence indicators to stop reflecting users' true activity. According to reports from IT administrators, the problem first appeared in the morning hours across the UK and continental Europe. Colleagues who were demonstrably active — sending messages, attending meetings — suddenly appeared as Away or Offline to their teammates.

Crucially, other Teams functions remained intact. Chat messages went through, calls connected, and meetings ran normally. For many, that created a false sense of security: if everything else works, the presence glitch must be a minor cosmetic bug, right? In fact, the discrepancy between functional messaging and broken presence was a hallmark of this incident, one that Microsoft's advisory later highlighted. Some users even assumed their own client was to blame, prompting them to clear caches, sign out, or even reinstall Teams — actions that did nothing to resolve a cloud-side problem.

The geographic scope was uneven. While Microsoft stated TM1394359 primarily hit the EMEA region, users in North America and Asia reported seeing incorrect presence for colleagues in the affected area. That ripple effect meant the outage's impact spread far beyond the initial routing fault, as anyone whose workflow depended on knowing the availability of EMEA-based colleagues suddenly found themselves navigating blind.

Why Presence Outages Hit Harder Than You Think

Presence might seem like a convenience feature — a small green, yellow, or gray icon next to a name. But for the people who keep an organization running, it's operational infrastructure. When a receptionist can't tell whether the on-call engineer is available, or a call queue routes an urgent customer to someone who appears Offline but is actually at their desk, the consequences aren't cosmetic. They're workflow failures.

During the June 17 disruption, reports poured in of front-desk staff unable to reach first responders, dispatch teams resorting to guesswork, and help desks fielding a flood of tickets from users who thought their own Teams client was broken. One common pattern: an individual contributor would see a colleague as Offline, send an email instead of an instant message, and then discover hours later that the colleague had been available all along. Multiply that by dozens or hundreds of interactions, and the productivity toll becomes significant.

"The green dot isn't just a status symbol," said one IT manager who asked not to be named. "It's how we decide who to ping, who to call, and who to escalate to in a crisis. When it's wrong, our whole incident response flow breaks down."

The outage also served as a stark reminder that presence in Teams is a shared cloud signal, not a thing your local client determines. Your Teams app doesn't independently decide whether a colleague is available; it receives that information from a Microsoft service. So when that service has a routing problem, no amount of local tinkering will fix what you see.

The Smarter Way to Diagnose a Presence Problem

Before you tell a user — or your entire org — to clear the Teams cache or reinstall, take a step back. The first question isn't "What's wrong with your client?" It's "Is this bigger than you?"

Start by checking with two or three colleagues in different locations and on different devices. If they all see the same people as Away or Offline, you're almost certainly dealing with a service incident, not a local glitch. Next, open the Microsoft 365 admin center and look at Service Health. If there's an active advisory — TM1394359 was the key reference on June 17 — stop any endpoint work and preserve the evidence. Communicate to your teams that presence is unreliable, and activate manual fallback procedures.

For administrators, Microsoft offers a diagnostic tool specifically designed for presence issues. In the Microsoft 365 admin center, you can run the Teams Presence diagnostic: enter the affected user's email address, and the tool checks the requirements needed to display that user's status correctly. If the diagnostic finds a tenant or configuration problem, follow its resolution steps. But if it comes back clean while the Service Health dashboard shows an incident, resist the urge to change anything on the client side.

Non-administrators can run the Teams Presence Based on Calendar Events connectivity test in the Microsoft Remote Connectivity Analyzer. That test checks whether a user's presence can update based on calendar events in Outlook. It's especially useful if the problem seems tied to scheduled meetings. Note that the diagnostic isn't available in GCC, GCC High, or Microsoft 365 operated by 21Vianet, and the Remote Connectivity Analyzer test isn't available in GCC and GCC High. In those environments, documenting the symptom matrix thoroughly and working through official support channels is the more effective path than guessing.

If Service Health is clear and the diagnostic doesn't point to a broad fault, then — and only then — does it make sense to investigate the local client. At that point, test one variable at a time: check identity, calendar integration, network connectivity, and finally the Teams app itself. Avoid the temptation to reset everything at once, which only obscures the real cause.

How We Got Here: A Fragile Presence Pipeline

June 17 wasn't the first time Teams presence went sideways, and it won't be the last. In February of this year, a different underlying component failure caused Teams presence to show users as Offline for hours. That incident, also documented by WindowsForum and other outlets, had a different root cause but taught the same lesson: presence isn't a local feature you can fix on your own.

Both outages highlight a structural fragility in Teams' architecture. Presence depends on a complex chain of signals — user activity on the desktop, login state across devices, calendar entries, manual status changes — all fed into a cloud service that then distributes the result to every user who shares a relationship with that person. When any link in that chain breaks, the whole signal can fail, regardless of whether chat, meetings, or file sharing continue to work.

And because presence is so deeply integrated into everyday workflows — call queues, escalations, quick decisions about who to message — even a brief outage can cascade into slower response times, missed critical communications, and a spike in help-desk tickets from users who don't realize the problem is on Microsoft's end.

What to Do Now: Your Incident Playbook

If you're caught in a future presence outage, here's what to do — and, just as important, what not to do:

For end users

  • Don't sign out, clear the cache, or reinstall Teams. These actions won't fix a cloud-side problem and may lock you out of other working features.
  • Do check with a few colleagues to see if they're seeing the same thing. If they are, report the issue to your IT team with the specific names and when you first noticed it.
  • Do use alternative communication methods: send a chat message even if the person appears Offline (it may still go through), or fall back to email or phone if the matter is urgent.

For IT administrators

  • First, verify the scope. If multiple users across different offices or networks see the same incorrect presence, head to the Microsoft 365 admin center and check Service Health. Look for an advisory like TM1394359.
  • Second, run the Teams Presence diagnostic on one or two representative users. If it finds nothing and Service Health shows an incident, communicate that it's a Microsoft-side issue and that local fixes won't help.
  • Third, activate your manual fallback for call queues, reception desks, and escalation workflows. Give front-line staff a printed or shared duty roster, a temporary phone tree, or a defined list of who to contact directly. Make it explicit: "Offline does not mean unreachable right now."
  • Fourth, manage the help desk. Send an all-staff communication telling users what to report (who appears wrong, who's viewing them, whether other functions work) and what not to do (no reinstalls, no repeated sign-outs). This alone can cut the ticket flood dramatically.
  • Finally, once Microsoft resolves the incident, see if you need to refresh the presence cache for any users. Only then consider client-side fixes for individuals who still show incorrectly.

What to Watch Next

Microsoft has a history of resolving these routing-related incidents within a few hours, and TM1394359 was no exception — systems recovered by the end of the day on June 17. However, the company hasn't shared a detailed post-mortem, and with presence depending on an ever-evolving set of cloud services, future disruptions are inevitable.

The silver lining: organizations that build a basic presence-incident plan now will be far better off than those that rely on the reflexive cache-clear. A simple runbook — check Service Health, run the diagnostic, switch to manual call routing — can turn a chaotic hour into a managed inconvenience. And that's a lesson worth remembering long after the green dots come back.