The first person to tell an MSP about a Microsoft 365 outage should not be the client who cannot open Outlook. I would rather a Grok Bot routine check status.cloud.microsoft for me, tell me when Microsoft posts an incident, keep watching while it is open, and tell me when it is marked restored. If customers might be affected, I want the same bot to draft a notice I can approve. It should not send anything on its own.
That is the whole job. Grok Bot is the monitor. The public status page is the source. A routine is the schedule. Everything else in this post – the admin centre Service health page, and the Graph API behind it – is useful context for later. It is not the starting point.
I am writing this on Friday, 13 November 2026, in Sydney. While I was putting the post together, the public page was already showing a service degradation: users may be unable to connect to multiple Microsoft 365 services, including Exchange Online, Microsoft Teams, SharePoint Online and Microsoft 365 Copilot. Microsoft had posted a current status, a previous status, and a time for the next update. That is exactly the sort of event I want Grok Bot to catch and stay with, rather than me discovering it in a ticket queue.
What Grok Bot is actually watching
Microsoft documents the public service status page as the place to check when you cannot sign in to the admin centre. The official write-up is How to check Microsoft 365 service health. The page is unauthenticated, so a Grok Bot routine can fetch it without a tenant sign-in. That is the point. If the admin centre itself is hard to reach, you still have a public source.
The site is a status page, not a full history. I checked what it actually exposes, rather than inventing an API. The page’s own code loads a current Microsoft 365 post from https://status.cloud.microsoft/api/posts/mac, and it publishes the same item as RSS at https://status.cloud.microsoft/api/feed/mac. There is a matching Power Platform feed at /api/feed/ppac, and the page points at Microsoft’s Azure status RSS for Azure. The Microsoft 365 post I fetched included a title, a status such as “Service degradation” or “Service restored”, timestamps, and a message with user impact, the current status, earlier updates, and a “Next update by” time. That is enough for a bot to notice a new incident, see whether the wording has changed, and notice when the status returns to available or restored.
One practical detail is worth knowing. The public page itself refreshes those posts on a five-minute interval. That is in the page’s own code. It is not a published Microsoft SLA for how quickly an update will appear. Microsoft often says when the next update is due inside the post. Grok Bot should treat that time as a promise to check against, not as a guarantee.
The public page is also broad. It tells you about a widespread issue Microsoft has chosen to post there. It does not tell you whether a particular tenant is affected, and it will not list the quieter advisories that show up in a tenant’s own Service health view. I will come back to that difference later. For the first routine, the public page is the right source because Grok Bot can read it with no extra permissions.
Set up a Grok Bot routine to watch and alert
You can do this on a dedicated status bot, or add the routine to a bot you already use for monitoring. I already use Grok Bot routines for a morning news brief, which I walked through in How to Use Grok Bot to Monitor MSP News and Security Updates. This is the same idea, pointed at one official page.
The app locations I will point you to are ones I have verified. Click the agent’s name in the chat header, or use Cmd+Shift+I, to open the per-agent info pane. Saved routines sit in that pane, under the computer preview. Check the timezone under Settings, on the General tab, opened from the sidebar account button at the bottom-left, or with Cmd+,. If you want the bot named and described clearly, the gear beside the X in the info pane opens the per-agent settings for avatar, name, title and description.
Create the routine in chat. Routines usually start within a few minutes either side of the time you set. If the run must start right on the minute, say “exactly” or “sharp”.
Here is the prompt I would use:
Create a routine called Microsoft 365 public status watch. Every 15 minutes during my Sydney business hours, check https://status.cloud.microsoft/ and the Microsoft 365 RSS feed at https://status.cloud.microsoft/api/feed/mac. You can also read the current post at https://status.cloud.microsoft/api/posts/mac.
Compare the current title, status and message with what you saw on the last run. If nothing material has changed, stay silent.
If a new incident or service degradation is posted, or if the status, title or message has changed, post an alert in this chat. Include:
- the title and current status
- the affected services, in plain English
- the current update, and what changed since last time
- the "Next update by" time, converted to Sydney time
- a link to https://status.cloud.microsoft/
Do not invent endpoints or details that are not on the page or in the feed. Do not sign in to a tenant for this routine. Do not email or message anyone else. If the page cannot be reached, say so once and try again on the next run.Fifteen minutes is a starting cadence, not a law. The page is already checking about every five minutes, so you can tighten the routine if you want it closer to that. Outside business hours you might run it less often, then keep a closer watch once an incident is open. What matters is that Grok Bot compares each run with the last one, and only speaks when something has changed.
Keep watching during the outage
An alert is only the start. Once Microsoft has posted an incident, I want Grok Bot to stay with it. The useful work is noticing what changed in the update, not repeating the same paragraph every quarter of an hour.
Ask it, in the same chat, to tighten the watch for as long as the incident is open. I would tell it to check again at or just after the “Next update by” time, and otherwise on a short interval, and to report only when the current status text, the list of affected services, or the overall status has changed. If Microsoft slips past the promised update time with no new post, I want the bot to say that too.
A during-outage prompt looks like this:
An incident is open on https://status.cloud.microsoft/. Until the status is Service restored or Available, watch it more closely. Check the current Microsoft 365 post and RSS feed at least every five minutes, and again at the "Next update by" time Microsoft has published, in Sydney time.
Only message me when something has changed: the status, the title, the list of affected services, or the current status text. Quote the new current status in a few lines, say what changed since the last update, and give the next promised update time. If that time passes with no new post, tell me once. Do not notify customers. Do not invent progress that Microsoft has not posted.That is also how I would have wanted it to behave this morning. The public post already had a current status and a previous status in the same message. A bot that only looks at a timestamp can miss a wording change. Compare the text.
Report when it is resolved
When Microsoft marks the issue as restored, I want a short all-clear in the same chat: what was affected, when it started, when it was restored, and a reminder that the public page is a broad signal, not proof that every tenant is back to normal. Then the routine can go back to staying quiet.
The resolution prompt:
If https://status.cloud.microsoft/ marks the current Microsoft 365 incident as Service restored or Available, post a resolution report in this chat and then return to the quieter watch. Include the original title, the services that were listed as affected, when the issue was first posted, when it was marked restored, and a short timeline of the updates you saw. Say clearly that this is the public status, not a tenant-by-tenant confirmation. Do not send any customer message unless I ask you to draft one.Draft the customer notice, then wait for approval
This is where the same Grok Bot work becomes useful for an MSP. If Exchange Online, Teams, SharePoint or Outlook might be affected, customers will ask. I would rather answer from Microsoft’s own words, in a calm note I have actually read, than type one under pressure.
The important rule is that Grok Bot drafts, and you send. Do not let the routine email clients, post to a Teams channel, or update a status page on its own. Leave the draft in the chat. You decide whether the incident is material enough to mention, whether the wording is right, and when it goes out. The same applies to the all-clear.
A prompt for that draft:
Draft a short customer notice, in plain English, based only on the current public incident at https://status.cloud.microsoft/. Write it as an MSP note I can send if I choose to. Include what Microsoft says may be affected, that Microsoft is working on it, a link to the public status page, and that we will follow up when the status is restored. Keep it factual. Do not claim we have confirmed impact in the customer's tenant. Do not apologise for a fault we did not cause, and do not guess at a resolution time.
Leave the draft in this chat. Do not send it, email it, or post it anywhere. I will approve or edit it first. Also draft a matching all-clear I can use once Microsoft marks the issue restored, and hold that back as well.If you later want the approved text in Outlook or Teams, you can ask the bot to place a draft where you work. That is a separate, approved step. It is not part of the watch routine.
A deeper option: tenant Service health
The public page is the wide, no-sign-in view. Microsoft’s fuller picture for a given organisation still lives in the Microsoft 365 admin centre, under Health, then Service health, which the same Learn article describes. That view is tenant-specific. It lists incidents and advisories that apply to the services that tenant uses, with an issue ID, a history of updates, and, if you want them, email notifications. Roles such as Service Support admin and Helpdesk admin can see it. Planned maintenance is not in Service health; that sits in Message centre.
The programmable version of that tenant view is the service communications API in Microsoft Graph. The permission for health issues is ServiceHealth.Read.All, as delegated or application access, granted by an administrator. Message centre posts are a different permission. Unattended monitoring is the application-permission path, which Microsoft describes for backend alert services in Access service health and communications in Microsoft Graph.
I already have a Grok Bot doing that deeper check in a tenant security routine. It is not watching the public page. It reads Service health for that tenant and includes it in a morning report. On a typical day it has found a dozen or more unresolved items, mostly advisories – a Copilot agent opening the wrong window, a SharePoint knowledge-agent limitation, an Exchange group-reply problem – rather than a wide outage. That is useful, and it is a different job. The public page would have been quiet on those mornings. The tenant view is noisier and more precise. If you add it, keep the public-page routine as the early, permission-free alert, and treat tenant Service health as the follow-up that answers “is this likely affecting this customer?”
I have also written about using a specialist Grok Bot when something in a tenant already looks wrong, in How Grok Bot Simplifies Security Checks and Investigations. Status monitoring is the earlier step: know that Microsoft has posted an issue before you start digging.
Sample prompts
These are the four prompts together, so you can paste them as you set this up.
Routine setup:
Create a routine called Microsoft 365 public status watch. Every 15 minutes during my Sydney business hours, check https://status.cloud.microsoft/ and https://status.cloud.microsoft/api/feed/mac. Compare the title, status and message with the last run. Stay silent if nothing has changed. If a new incident or service degradation appears, or if the post has changed, alert me in this chat with the title, status, affected services, what changed, the next update time in Sydney time, and a link to the page. Do not invent details. Do not sign in to a tenant. Do not contact customers.During an outage:
Watch the open incident on https://status.cloud.microsoft/ more closely until it is Service restored or Available. Check at least every five minutes, and at the "Next update by" time. Only message me when the status, title, affected services or current update text changes, or if the promised update time passes with no new post. Do not notify customers.Resolution report:
When the public Microsoft 365 incident is marked Service restored or Available, post a short resolution report in this chat: original title, affected services, first-posted time, restored time, and a brief timeline. Remind me this is the public status, not a per-tenant confirmation. Then return to the quieter watch. Do not send a customer message unless I ask for a draft.Customer notice draft:
Draft a short customer notice from the current public incident only. Say what may be affected, that Microsoft is working on it, and link to https://status.cloud.microsoft/. Do not claim confirmed impact in a customer's tenant, and do not guess a resolution time. Leave the draft in this chat. Do not send it. Also prepare an all-clear draft and hold that back until I approve it.What I want from this
The useful design is a Grok Bot that watches one official public page, speaks when the post changes, stays with the incident, and writes a customer note I still have to approve. It will not replace the admin centre, and it will not tell you with certainty that a given tenant is affected. It will mean you heard about the outage from your own bot, in your own chat, with Microsoft’s wording in front of you, before the first customer call.
