The Service Health Dashboard in the Office 365 admin portal provides customers with a view of the health of the wide variety of services in Office 365. Microsoft uses the Service Health Dashboard to notify us about known issues, incidents, and planned maintenance. Now Microsoft has given the SHD a much needed overhaul, with a new look that they hope will provide a clearer picture of the status of our tenants. The new SHD is rolling out to customers right now, and should be completed by the end of February.
Looking at the new SHD (on the left) and the previous design (on the right) the changes are mostly cosmetic. If you happen to prefer the old SHD, you can still get to it by clicking a link to the “v2 Service Health page”, but I don’t think anyone is going to cling to the old version. The new one is easy to read and use, so there’s no real reason not to start using it, and it is the default SHD view anyway.
The biggest improvements come to light after you click on an incident or advisory to see more information. A summary is presented, with just enough detail to let you know what’s going on.
The “Show details” link takes you to a full history of the incident, with a timeline of updates as Microsoft investigates and resolves the issue. This detail was also available in the previous SHD, it just wasn’t quite as obvious how to get to it. Interestingly, for the incident that was active while I was looking around the new SHD, there’s more information presented in the new SHD than the old one.
Customers have long complained about the Service Health Dashboard, with most of the gripes being about the timeliness and accuracy of the information provided by Microsoft. Timeliness is a tough one, because customers will often make up their mind that there is a problem in Office 365 well before Microsoft has gathered enough information from support tickets and their own monitoring to confidently post an incident to the SHD about it. Back in June 2015 Microsoft announced that they had reduced the time between an incident occurring and the first alert appearing in affected customers’ SHD by 60%, but I suspect they’ll never be able to fully eliminate the perception of a delay.
Accuracy is the other primary complaint, and the new SHD provides a feedback channel for customers to let Microsoft know what they think about each incident notification. Hopefully constructive feedback from customers helps Microsoft to further improve the information published in the SHD.
Personally, I’m still disappointed in the lack of email notifications. Yes, there are notifications in the various Office 365 admin apps that Microsoft maintains for Windows, iOS and Android, although mine have a habit of logging themselves out, which causes the notifications to stop showing up. Notifications are also easily missed when you aren’t actively using a device, which is why I prefer email notifications. Much like the Message Center, this is a problem I am solving with PowerShell for now, and I will likely have a script to share in the near future.
The Office 365 road map has an item in development that will see email and text notifications available, but no timeline on when that feature will arrive.
Of course, the SHD isn’t just for admins. It’s also a useful resource for non-technical people in the organization who need to be aware of service health issues in Office 365. Rather than requiring them to ask one of your IT team for information, you can simply grant them Service administrator access in Office 365 (note this also gives them access to open support tickets).
All up the new Service Health Dashboard is a reasonable improvement for Office 365 customers.
[adrotate banner=”50″]
Is microsoft eventually going to come out with email alert notifications on SHD?
I paul have made some script around same module if required you can use the same
Hi Paul. Good information as always.
I opened a case with Microsoft because I’m not able to connect with the module you mentioned nor any other script. I was told it’s no longer possible and they referred me to this new dashboard. That can’t be true…. Correct? He pointed out the article I had open was dated 2014, but if this feature was disabled I’m sure someone would have mentioned it online. 🙂 And O365ServiceCommunications was recently updated to 1.5.
I’ve got two Global Admin IDs that I use in both browsers and PowerShell, and when I try to Invoke-RestMethod both IDs receive the error below. It looks like Friday is going to start with some gratuitous head scratching.
Invoke-RestMethod : Sendera:UnauthorizedUnauthorized
At C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules\O365ServiceCommunications\functions\New-SCSession.ps1:60 char:22
+ Cookie = Invoke-RestMethod @Splat | Select-Object -Expand …
+ ~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-RestMethod], WebException
+ FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeRestMethodCommand
I’ve just tested it following the instructions on the Github repo for Matt’s module. It works fine with an account that has Service Administrator rights in my O365 tenant and that does not have MFA enabled. Admin accounts with MFA enabled throw a similar error to yours.
It worked for me as well until now 🙁 multiple tenants all the same issue.
It’s been working fine for me. Possible that at some times it has a bug or an error due to the API it hits.
I believe Microsoft is planning to add email/txt notifications for the service health dashboard in future, so that might just solve the problem for all of us anyway.
Hi Paul,
I have modified the service alert script as per my requirement it was working fine for 2 months and now it failed with same error posted by
Paul N. says
July 28, 2017 at 10:21 am
Could you please check if there is any update on the error as this is very important script and we need it to monitor the service alerts.
Hi
What is the powershell you are running to get those events?
Thank you
I’m using a PowerShell module called O365ServiceCommunications (https://github.com/mattmcnabb/O365ServiceCommunications)