The Exchange Admin Center Went Down — Did Your Monitoring Know Before Your Users Did?

On October 12, Microsoft confirmed what thousands of admins had already worked out the hard way: the Exchange Admin Center outage was caused by a configuration change. A rollback restored service, the status page went green, and everyone moved on. Stop us if you have heard this one before — because if you have run IT for more than a year, you have.

Here is the part that should bother you more than the outage itself. Most IT teams did not learn about the EAC failure from their monitoring stack. They learned from a ticket saying nobody can edit distribution groups, or a Slack message, or a post on X. Their monitoring consoles sat green the whole time, because they were watching mail flow, mailbox databases, and server resources — not the admin plane the entire team depends on to manage any of it.

When the management console for your most critical workload becomes a single point of failure, and your tooling can neither see that failure nor help you work around it, you do not have a monitoring gap. You have a tooling architecture problem.

The Problem: Your Admin Plane Is SaaS, and Almost Nobody Monitors It

Exchange Admin Center is not alone. Intune, the Azure portal, the Meraki dashboard, the vSphere client — entire categories of IT work now happen inside vendor-hosted web consoles. Those consoles receive configuration changes just like any other SaaS platform, and as Microsoft's own postmortem admits, sometimes those changes break things. The vendor will always fix it eventually. Your problem is everything that happens in between: you cannot manage mailboxes, you cannot touch distribution groups, you cannot onboard the new starter whose paperwork HR submitted on Friday.

Now layer on how most IT teams are actually tooled. A typical mid-size environment runs four to six disconnected products: PRTG or Zabbix for infrastructure, a separate RMM like NinjaOne, ConnectWise Automate, or Syncro for endpoint work, a standalone helpdesk like Freshservice or Jira Service Management, and a bookmarks folder full of vendor status pages. When EAC went down, the verification workflow looked like this:

1. Refresh the Microsoft 365 service health page and wait for it to acknowledge reality — status pages routinely lag 15 to 30 minutes behind.
2. Open the monitoring tool to see if anything fired. Nothing did, because it monitors workloads, not the admin plane.
3. Remote into a test workstation using whichever RMM product is not currently in use for something else.
4. Manually run PowerShell to confirm what is broken and what still works.
5. Hop back to the helpdesk to link the growing pile of user tickets.

Five tools, six tabs, zero shared timeline. The technician is the integration layer — the only thing connecting the alert to the action to the ticket is a human copy-pasting between windows.

The math gets ugly fast. An MSP managing 30 clients hits an EAC outage at 9am on a Monday. Every client has at least one request that needs the console: a new mailbox, a permission change, a shared folder fix. If detection takes 25 minutes and confirmation another 15, you have burned 40 minutes of SLA clock across 30 clients before anyone has even confirmed it is a vendor-wide problem. Ticket volume spikes, end users get frustrated, and the tech who is three weeks into onboarding is learning your runbooks during a live incident because the documentation lives in a tool nobody had open.

How AlertMonitor Closes the Gap

This is exactly the scenario AlertMonitor was built for — one platform where infrastructure monitoring, RMM, helpdesk, patching, and network visibility share the same data and the same timeline.

The RMM capabilities sit inside the same console as your alerts. When a check fails on an admin workstation, a technician opens the alert, launches a remote session, and runs a saved script against a device group — without switching tabs. There is no boundary between the monitoring product and the management product, because there is no separate management product.

Script results feed back into the monitoring data. Push an endpoint health check to your 20 admin workstations and every result — reachable, unreachable, degraded — lands on the same timeline as the alert that triggered the investigation. Automated remediations and manual technician actions are both recorded, so your post-incident review writes itself instead of being reconstructed from memory and chat logs.

Compare the two workflows:

• The old way: status page, then a silent monitoring tool, then a separate RMM for manual PowerShell, then manual helpdesk updates. First confirmed picture: 40 to 60 minutes.
• The AlertMonitor way: the endpoint check alerts, the technician clicks through to a remote session in the same console, runs the fallback script across the device group, reviews results on the timeline, and links the affected tickets. First confirmed picture: minutes, with an audit trail already built.

One more thing teams consistently underinvest in: the fallback path itself. Exchange Online PowerShell keeps working when the web console does not — but only if the module on your admin jump hosts is current and the runbook is tested. Because patch management lives in the same platform, keeping those admin workstations and modules up to date is part of the same routine, not a separate project that never gets a maintenance window.

What You Can Do Today

1. Monitor the admin plane, not just the workloads

Deploy a connectivity check to your admin workstations or jump hosts that tests the consoles your team depends on. In AlertMonitor, push this as a script to a device group and let a non-zero exit code drive the alert:

# Admin-plane health check — deploy via RMM to admin workstation device group
# Exit code 1 appears on the monitoring timeline and can trigger an alert.

$endpoints = @(
    'admin.exchange.microsoft.com',
    'outlook.office365.com',
    'login.microsoftonline.com'
)

$results = foreach ($ep in $endpoints) {
    $t = Test-NetConnection -ComputerName $ep -Port 443 -WarningAction SilentlyContinue
    [PSCustomObject]@{
        Endpoint  = $ep
        Reachable = $t.TcpTestSucceeded
        CheckedAt = (Get-Date).ToString('yyyy-MM-dd HH:mm:ss')
    }
}
$results | Format-Table -AutoSize

$eac = $results | Where-Object { $_.Endpoint -eq 'admin.exchange.microsoft.com' }
if (-not $eac.Reachable) {
    Write-Output 'ALERT: Exchange Admin Center endpoint unreachable from this workstation.'
    exit 1
}

2. Get a vendor-side view without refreshing a status page

The Microsoft Graph service health API tells you what Microsoft officially knows — pull it on a schedule and alert on anything that is not fully operational:

# One-time: Install-Module Microsoft.Graph.Devices.ServiceAnnouncement -Scope CurrentUser
# Microsoft 365 service health via Microsoft Graph
# Requires ServiceHealth.Read.All consent

Connect-MgGraph -Scopes 'ServiceHealth.Read.All' -NoWelcome

Get-MgServiceAnnouncementHealthOverview -All | Where-Object { $_.Status -ne 'serviceOperational' } | Select-Object Service, Status | Format-Table -AutoSize

Run this from your jump host through the AlertMonitor agent and the output lands on the same timeline as the endpoint check from step 1. Two independent signals, one picture, no tab-switching.

3. Build and test the fallback runbook

PowerShell against Exchange Online keeps working when the web console does not. Save this in your platform as a shared script so any technician can execute it from a remote session in seconds:

Connect-ExchangeOnline -UserPrincipalName admin@contoso.com

# Task that would normally need EAC: add a member to a distribution group
Add-DistributionGroupMember -Identity 'Finance-Team' -Member 'jdoe@contoso.com'

# Quick mailbox sanity check for a user-reported issue
Get-MailboxStatistics -Identity 'jdoe@contoso.com' |
    Select-Object DisplayName, ItemCount, LastLogonTime

Test it quarterly — an untested runbook is a hope, not a runbook.

4. Push verification at scale, and let the timeline do the reporting

During the next vendor incident, do not verify one machine manually. Push a health snapshot across the whole device group at once:

# Endpoint health snapshot — run across a device group via RMM
Get-CimInstance Win32_LogicalDisk -Filter 'DriveType=3' |
    Select-Object DeviceName,
        @{n='FreeGB';e={[math]::Round($_.FreeSpace/1GB,1)}},
        @{n='FreePct';e={[math]::Round($_.FreeSpace/$_.Size*100,1)}}

Get-Service -Name 'WinRM','wuauserv' |
    Select-Object Name, Status

Every result feeds the monitoring timeline automatically. When the client asks what happened, when you knew, and what you did about it, the answer is a link — not a 40-minute reconstruction from memory.

The Bottom Line

Microsoft will keep shipping configuration changes to Exchange Admin Center, and occasionally one will take the console down with it. That part is out of your control. What is in your control: whether your team finds out from a monitoring alert backed by a tested fallback script in the same console, or from the first of thirty angry tickets.

If your RMM, monitoring, and helpdesk still live in separate tools, the next vendor outage is your next stress test — and you already know how it ends.

Related Resources

AlertMonitor RMM & Remote Management AlertMonitor Platform Overview Book a Demo RMM & Remote Management Resources