# Service Health

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/service-health

## Quick definition

Service Health shows you if Microsoft’s cloud services like Exchange Online, Teams, or SharePoint are working properly. It displays current problems, past issues, and planned maintenance. You can check it in the Microsoft 365 admin center or Azure portal. This helps you know if a problem is on Microsoft’s side or your own.

## Simple meaning

Think of Service Health like a live status board for a big apartment building. The building manager (Microsoft) monitors everything: electricity, water, internet, and elevators. If the internet goes down in the whole building, the manager posts a notice saying "Internet is down for everyone due to a cable cut. We are fixing it." As a tenant, you check that board before calling your own IT person, because it might not be your router’s fault. In the same way, Service Health tells you if Microsoft 365 or Azure services have a known issue. It shows three types of messages: advisories (minor issues or upcoming changes), incidents (active problems like outages), and maintenance (planned updates, hopefully with no downtime). It also gives you a history of past issues, so you can see if a slowness you noticed last week was caused by Microsoft. This is incredibly useful for IT professionals because it saves them from wasting hours troubleshooting something they cannot fix, the cloud provider already knows about it and is working on it. Instead, they can focus on what they can control: their own network, devices, and users. Service Health also lets you filter by service and region, so you only see what affects you. For example, if you only use Teams and Exchange, you don’t need to worry about SharePoint outages. The service also sends email or SMS alerts when something changes, so you don’t have to keep refreshing the page. In short, Service Health is your go-to source for knowing whether the cloud is healthy or if something is broken at the provider’s end.

## Technical definition

Service Health in Microsoft 365 and Azure is a centralized monitoring service that aggregates telemetry from Microsoft’s global infrastructure to provide real-time and historical status of cloud services. It is part of the Microsoft 365 admin center (under Health > Service Health) and the Azure portal (under Help + support > Service Health). The underlying system relies on probes, synthetic transactions, and user-reported data to detect anomalies. When a probe fails a threshold (e.g., login requests fail 5% above baseline for longer than 5 minutes), an incident is automatically created. Once an incident is opened, Microsoft engineers triage, classify severity (single-user, multi-user, or tenant-wide), and begin mitigation. The Service Health dashboard reflects the current state: green indicates healthy, yellow indicates a warning (advisory), and red indicates an active incident. Each incident includes a description, affected services, impact scope, current status (e.g., investigating, deploying a fix, restoring), and a timeline of updates. Historical data is available for up to 30 days in the standard view, and up to 90 days with an administrative audit log. Administrators can configure email or SMS notifications using the Service Health API or the admin center settings. The service also integrates with Microsoft 365 Message Center to show planned changes and maintenance events, often with a notice period. For Azure, Service Health also includes Resource Health (per-resource status) and Event Log for subscription-level incidents. The service uses a global load balancer to route traffic around unhealthy regions automatically, but Service Health informs administrators if traffic is being rerouted. Technically, Service Health data is transmitted over HTTPS using Microsoft’s internal API, and administrators can access it via the Microsoft Graph API for programmatic integration with third-party monitoring tools. The API returns JSON objects with properties like status, severity, classification, and affectedTenants. This allows IT teams to send alerts to Slack, Teams, or PagerDuty automatically. The underlying infrastructure is maintained by Microsoft’s datacenter operations team, and the Service Health data itself is stored in redundant storage to ensure availability even during major outages. Understanding Service Health is critical for cloud administrators because it distinguishes between issues in the cloud provider’s control and issues in the customer’s control, preventing wasted troubleshooting efforts.

## Real-life example

Imagine you are a facilities manager for a large office building. Every morning, you check the building’s central control panel. This panel shows the status of electricity, water, heating, internet, and elevators. If the internet is out, the panel might say "Internet, Outage, Provider repairing, Expected resolution in 2 hours." You know immediately that it is not your office’s router that is broken, the internet company (the provider) is fixing it. You don’t call your own electrician to fix it. You simply inform the tenants: "The internet is down due to a problem at the provider side. They are working on it." That is exactly what Service Health does. The building (your Microsoft 365 or Azure environment) has many services: Exchange Online (email), Teams (chat and meetings), SharePoint (files), and Azure VMs (virtual machines). Service Health is the central status board that tells you whether each service is healthy or experiencing a problem. If you see a red light for Exchange Online, you know that sending and receiving email is currently impacted for many customers, and Microsoft is investigating. You don’t need to restart your mail server or check your firewall, it is not your problem to solve. You just communicate to your users and wait for the fix. If the status is yellow, it might mean a minor issue that affects only a few users or a planned maintenance window. For example, Microsoft might say "We are updating SharePoint to add new features. This may cause brief slowness for 30 minutes." That is like the building manager saying "We are upgrading the elevator system tomorrow from 2–4 AM. Please use stairs during that time." You plan accordingly. Without Service Health, you would be guessing whether a problem is at Microsoft or in your own network. That would lead to hours of troubleshooting, unnecessary tickets, and frustration. So Service Health acts as a reliable, official source of truth about the cloud provider’s health, allowing you to focus your energy on things you can actually fix.

## Why it matters

Service Health matters because it directly impacts how IT professionals diagnose and respond to service disruptions. In a traditional on-premises environment, when something breaks, you check your own servers, network, and storage. But in the cloud, many issues are caused by the provider. Without Service Health, you might spend hours rebooting servers, checking DNS settings, or rerouting traffic, only to find out that the problem was a known Microsoft outage that they were already fixing. That is wasted time and wasted effort. Service Health gives you immediate clarity: is this my problem or Microsoft’s problem? This distinction is critical for reducing mean time to resolution (MTTR). If the issue is at Microsoft, you don’t fix it, you just inform stakeholders and wait for updates. If the issue is not listed in Service Health, then you know it is likely a local problem (your network, your devices, your configurations) and you can start troubleshooting. Service Health also helps with compliance and auditing. Some regulations require you to document service interruptions. Service Health provides timestamps, root cause analyses (post-incident reports), and status updates that you can export for compliance records. It also helps with resource planning. If you see a planned maintenance event that will affect your critical service, you can schedule your own changes around it. Service Health alerts can be integrated into your existing monitoring systems. For example, if you use System Center Operations Manager (SCOM) or a third-party tool like Datadog, you can pull Service Health data via the Graph API and trigger alerts in your own dashboard. This keeps everything in one place. For IT managers, Service Health also enables better communication to end users. Instead of saying "I don’t know why email is slow," you can say "Microsoft has reported a known issue with Exchange Online. Here is the link to the advisory." This builds trust and reduces helpdesk tickets. Service Health is a foundational tool for cloud management, it saves time, reduces confusion, improves communication, and supports compliance. It is not just a nice-to-have; it is essential for any organization that relies on Microsoft cloud services.

## Why it matters in exams

Service Health appears in the Microsoft 365 Certified: Messaging Administrator Associate (MS-102), Microsoft 365 Fundamentals (MS-900), and Azure Administrator Associate (AZ-104) exams. In MS-102, Service Health is a core objective under "Monitor and troubleshoot Microsoft 365 services." You must know how to access Service Health, interpret different status types (incident, advisory, maintenance), configure notifications, and use the Service Health API. Exam questions often ask you to determine whether a reported issue is a tenant-specific problem or a Microsoft-wide incident. For example, you might be given a scenario where users cannot send emails, and you must decide whether to check Service Health first or check your own connectors. The correct answer is to check Service Health first. Another common question is about configuring email notifications for service health, you need to know that you can set them per service in the admin center. In MS-900, Service Health is part of the "Describe Microsoft 365 service lifecycle and support" section. You need to know that Service Health provides real-time status of Microsoft 365 services, and that the Message Center provides planned changes. The exam may ask you to differentiate between Service Health and Message Center. A typical question: "An administrator notices that users are unable to access Teams. Where should they check first?" Answer: Service Health. In AZ-104, Service Health appears under "Monitor and troubleshoot Azure infrastructure" as part of Azure Monitor. You need to understand Azure Service Health, Resource Health, and the Activity Log. A typical question might present a scenario where a virtual machine is unresponsive, and you must check Resource Health (which is part of Azure Service Health) to see if the issue is at the host level or the VM level. You might also be asked how to set up alerts for service health incidents using Azure Monitor. The exams often use multiple-choice, scenario-based, and drag-and-drop questions. For example, a drag-and-drop question might ask you to place the steps for configuring Service Health alerts in the correct order: 1. Go to Service Health in the Azure portal, 2. Click on Health Alerts, 3. Create a new alert rule, 4. Select the service, 5. Choose notification type (email/SMS), 6. Save. So in summary, for all three exams, you must be comfortable with the Service Health user interface understand the difference between incident/advisory/maintenance know how to configure notifications and be able to distinguish between provider-side and customer-side issues. That knowledge is tested directly.

## How it appears in exam questions

Service Health questions appear in three main patterns: scenario-based troubleshooting, configuration steps, and conceptual differentiation. In scenario-based questions, you are given a description of an issue: "All users in your organization report that they cannot access Microsoft Teams. The status in the Teams admin center shows everything as healthy. What should you do first?" The correct answer is to check Service Health in the Microsoft 365 admin center. The distractor answers might include restarting the Teams client, checking local DNS, or contacting Microsoft support, all of which are premature until you confirm it is not a Microsoft-wide outage. Another scenario: "You receive an alert that some users in Europe cannot send emails. The issue started 30 minutes ago. Your local network and firewall show no problems. What should you do?" The answer is to check Service Health and see if there is an advisory or incident for Exchange Online in the Europe region.

Configuration-based questions ask about setting up notifications. For example: "You need to ensure that the IT team receives an email whenever a new incident is posted in Service Health. What should you configure?" Options might include: Configure email notifications in the Microsoft 365 admin center under Service Health settings, or set up an alert rule in Azure Monitor. The correct answer depends on whether the question is about Microsoft 365 or Azure. In MS-102, you would configure it in the admin center. In AZ-104, you would use Azure Monitor alert rules. Another configuration question: "You want to receive SMS notifications for critical service health incidents. What must you do?" Answer: In Service Health settings, add a phone number and select critical incidents.

Conceptual differentiation questions ask you to compare Service Health to other tools. For example: "What is the difference between Service Health and Message Center?" Service Health shows the current and historical health of services (outages, incidents). Message Center shows planned changes and new features. Another example: "What is the difference between Azure Service Health and Azure Resource Health?" Service Health shows incidents that affect a subscription or region, while Resource Health shows the health of a specific resource (like a VM or database). These questions often appear in MS-900 and AZ-104. Also, in MS-102, you might be asked: "When would you use the Service Health API?" Answer: To integrate Service Health data into a third-party monitoring tool.

Finally, there are questions about interpreting the Service Health dashboard. You might be shown a screenshot with a yellow warning icon next to SharePoint and asked: "What does this indicate?" Answer: An advisory (non-critical issue or planned maintenance). Or a red icon: "Active incident." So you must memorize the color codes and terminology.

## Example scenario

You are the IT administrator for a medium-sized company that uses Microsoft 365 Business Premium. Your users are located in North America and Europe. One Tuesday morning, you start receiving frantic calls from your sales team: they cannot log in to Microsoft Teams. The error message says "Cannot connect." At first, you think it might be a local network issue. You check your firewall logs, everything looks normal. You ask a colleague in a different building if they can log in. They cannot either. Now you suspect it might be a Microsoft issue. You open the Microsoft 365 admin center, go to Health > Service Health. You see a red incident for Microsoft Teams with the message: "Some users in Europe and North America are unable to connect to Teams. We are investigating. Incident ID: TE12345. Next update within 30 minutes." You also see that Exchange Online and SharePoint are green. Now you know exactly what is happening. You send a company-wide email: "We are aware of the Teams outage. Microsoft has confirmed the incident and is working on a fix. Please monitor Service Health for updates. We will update you as soon as Microsoft provides more details." Your helpdesk tickets reduce dramatically because users see you are informed. You also note the Incident ID for your own records. After 45 minutes, you refresh Service Health and see the status has changed to "Deploying a fix." Another 30 minutes later, the status becomes "Restored." You confirm that your users can now log in. You close the ticket. Later, you download the post-incident report from Service Health (available for 30 days) to include in your monthly report. This scenario shows exactly how Service Health is used in real IT operations: as the first place to check for cloud issues, as a communication tool, and as a record-keeping source. Without it, you would have wasted hours troubleshooting your own network, causing unnecessary panic and confusion.

## Common mistakes

- **Mistake:** Assuming any service issue is a Microsoft problem without checking Service Health.
  - Why it is wrong: Many issues are caused by local factors like misconfigured DNS, expired licenses, or corrupted user profiles. Blaming Microsoft without verifying wastes time and can lead to incorrect troubleshooting. Service Health is the objective source of truth.
  - Fix: Always check Service Health first. If the service is listed as healthy, the issue is likely local. Then start your own troubleshooting.
- **Mistake:** Confusing Service Health with Message Center.
  - Why it is wrong: Service Health shows real-time and historical incidents, outages, and advisories. Message Center shows planned changes and new features. They have different purposes and different update frequencies. Using one for the other causes confusion about whether an issue is active or planned.
  - Fix: Remember: Service Health = what is broken now. Message Center = what will change soon. If you need to know about an ongoing outage, use Service Health. If you want to know about an upcoming feature, use Message Center.
- **Mistake:** Only checking Service Health once and not refreshing during an incident.
  - Why it is wrong: Incidents can change status (e.g., from Investigating to Deploying fix to Restored). Not refreshing means you might tell users outdated information. Also, new updates may contain workarounds or expected resolution times.
  - Fix: Set up email or SMS notifications for incident updates. Alternatively, check Service Health periodically (every 30 minutes) during an active incident and communicate the latest status to stakeholders.
- **Mistake:** Forgetting to configure Service Health notifications.
  - Why it is wrong: Without notifications, the only way to know about incidents is to manually check the portal. This can lead to delayed detection and response. IT teams relying on users to report issues can miss early warnings.
  - Fix: Configure at least email notifications for critical incidents in the Microsoft 365 admin center under Service Health > Settings. For Azure, set up alert rules in Azure Monitor for Service Health events.
- **Mistake:** Ignoring advisories and maintenance events.
  - Why it is wrong: Advisories may warn about upcoming changes that could affect your users if not prepared. Maintenance events might cause temporary downtime. Ignoring them can lead to unexpected disruptions during business hours.
  - Fix: Review advisories and maintenance events weekly. Plan your own changes around them. If a maintenance event will affect a critical service, inform users in advance.
- **Mistake:** Not using the Service Health API for integration.
  - Why it is wrong: Relying solely on manual checks is inefficient for larger IT teams. The API allows you to integrate Service Health data into your existing dashboards and alerting systems, providing a single pane of glass.
  - Fix: Learn the Microsoft Graph API for Service Health. Use it to push alerts to Slack, Teams, or your ticketing system. This reduces manual overhead and ensures quicker response.

## Exam trap

{"trap":"The exam shows a scenario where a user cannot access a service, and one answer option is 'Check the Message Center' while another is 'Check the Service Health dashboard.' Many learners pick Message Center because they think it has all health updates.","why_learners_choose_it":"Learners often confuse Message Center with Service Health because both are in the admin center under the 'Health' section. The word 'Message' might sound like it includes current messages about outages. Also, some study materials don't clearly differentiate the two.","how_to_avoid_it":"Remember: Message Center is for planned changes and communications from Microsoft about new features. Service Health is for real-time and historical health status. If the question involves an active problem (e.g., users cannot log in), the answer is always Service Health first. If the question is about an upcoming feature or change, it is Message Center."}

## Commonly confused with

- **Service Health vs Message Center:** Message Center shows planned changes, new features, and upcoming updates from Microsoft. Service Health shows the current health status of services, including active incidents and past outages. Message Center is proactive (what will happen), Service Health is reactive (what is happening or has happened). (Example: If Microsoft announces that they are adding a new feature to Teams next month, that appears in Message Center. If Teams is down right now, that appears in Service Health.)
- **Service Health vs Azure Resource Health:** Azure Resource Health is a subset of Azure Service Health that shows the health of individual resources (like a specific VM or database), not the entire service. Service Health shows incidents affecting a whole subscription or region. Resource Health helps you determine if a problem is with your specific resource (e.g., VM is degraded) vs. a regional outage. (Example: If all VMs in your subscription are showing as unhealthy, check Service Health for a regional Azure incident. If only one VM is unhealthy, check Resource Health to see if it's a host issue or a VM-level problem.)
- **Service Health vs Microsoft 365 Admin Center Dashboard:** The admin center dashboard gives a summary card for Service Health but also includes user activity, licenses, and other metrics. Service Health is the dedicated page for health information. Some learners think the dashboard card is enough, but the full Service Health page provides detailed incident IDs, timelines, and status updates. (Example: The dashboard may show a green checkmark for 'All services healthy', but you must go to the Service Health page to see if there is an active advisory with a yellow icon. The dashboard does not show advisories.)
- **Service Health vs Support Tickets:** A support ticket is a request you open with Microsoft for a problem you need help with. Service Health is a self-service dashboard that shows known incidents Microsoft is already aware of. Opening a support ticket for an incident already shown in Service Health is unnecessary and wastes time. (Example: If you see an incident in Service Health for Exchange Online, you do not need to open a support ticket. If you see an issue not listed in Service Health, then you may need to open a support ticket.)

## Step-by-step breakdown

1. **Access Service Health** — In the Microsoft 365 admin center, go to Health > Service Health. For Azure, go to Help + support > Service Health. This is where you will see the overall status of all services. You must have appropriate admin permissions (Global admin, Service admin, or Billing admin) to view all details.
2. **Understand the Status Indicators** — Green checkmark = service is healthy. Yellow warning icon = advisory (non-critical issue, maybe slow performance or upcoming maintenance). Red X = active incident causing service degradation. Click on a status to see details. This is crucial because you must interpret the status correctly to decide next steps.
3. **Read the Incident or Advisory Details** — When you click on a red or yellow item, you see a panel with: Incident ID, Title, Description of impact, Affected services, Affected regions, Status (e.g., Investigating, Deploying fix, Restored), and a timeline of updates. This tells you exactly what Microsoft knows and what they are doing. You can also see estimated resolution time if available.
4. **Review Historical Issues** — Service Health keeps a history of issues for the last 30 days. You can filter by date range, service, and severity. This is useful for analyzing patterns, verifying if a past issue caused a reported problem, or generating compliance reports. You can also download a post-incident report (PIR) for each issue, which includes root cause analysis.
5. **Configure Notifications** — In the Service Health settings, you can opt to receive email notifications for incidents and/or advisories. You can choose which services to monitor and whether to receive messages about all changes or only critical incidents. You can also add SMS notifications for critical incidents (requires a phone number). For Azure, you create alert rules in Azure Monitor.
6. **Use the Service Health API** — For programmatic access, use the Microsoft Graph API endpoint: https://graph.microsoft.com/v1.0/admin/serviceAnnouncement/healthOverviews. This returns JSON with status of all services. You can integrate this into your own dashboards, ticketing systems, or monitoring tools like Splunk or Datadog. This step is more advanced but very useful for automation.
7. **Communicate to Stakeholders** — After identifying an incident, you should inform your users, helpdesk, and management. Use the details from Service Health (Incident ID, expected resolution time, scope) to provide clear, accurate updates. This reduces uncertainty and ticket volume. For ongoing incidents, plan to provide regular updates as the status changes.

## Practical mini-lesson

Service Health is not just a passive dashboard, it is an active tool that should be integrated into your daily IT operations. As a professional, you should check Service Health at the start of each day, especially if you support remote workers across different regions. A quick glance can alert you to overnight incidents that users may already be complaining about. But do not limit yourself to manual checks. Set up a workflow: when a new critical incident is posted, automatically create a ticket in your helpdesk system using the Service Health API. For example, using Power Automate, you can trigger a flow: 'When an incident is created in Service Health (critical severity), post a message to a Teams channel and create a ticket in ServiceNow.' This ensures no incident goes unnoticed. Also, understand the difference between an advisory and an incident. Advisories are not emergencies, but they often provide workarounds. For instance, an advisory might say: 'Some users may experience slow uploads to SharePoint due to a configuration issue. As a workaround, you can direct users to use the desktop app instead.' That information can be immediately passed to your helpdesk to reduce user frustration. Another practical use: when planning a change in your environment (like a firewall update), check Service Health to ensure there are no ongoing incidents that could complicate the rollback. If an incident is occurring, you might postpone your own change to avoid confusion. For compliance, you should document all relevant incidents. You can export Service Health history to a CSV file and store it with your change records. In an audit, this shows that you were aware of provider-side issues and took appropriate communication steps. What can go wrong? One common issue is notification fatigue if you subscribe to all alerts. You will get many messages, including low-severity advisories. To avoid this, filter notifications to only critical and medium severity, and then manually check advisories weekly. Another mistake is forgetting to update your notification contact. If your admin leaves, the email notifications go to an empty inbox. So periodically review your Service Health notification settings. Also, be aware that Service Health data is only available for the past 30 days for most users. If you need longer retention, you must export the data regularly. Finally, test your notification setup. Ask a colleague to simulate an incident (or wait for a real one) to verify that the email or SMS arrives. This ensures that when a real outage happens, you are alerted immediately.

## FAQ

**How often is Service Health updated?**

Service Health is updated in near real-time. When a new incident is detected or an existing one changes status, the dashboard updates within minutes. Historical data is updated retroactively as more information becomes available.

**Can I see Service Health for all Microsoft 365 services at once?**

Yes, the Service Health dashboard in the M365 admin center shows a list of all services with their current status. You can sort by status to see only unhealthy services. Azure Service Health also shows a summary of all services you use.

**Do I need a license to access Service Health?**

You need a valid Microsoft 365 or Azure subscription, and you must have administrative permissions (Global admin, Service admin, or at least the Service Health view permission). There is no additional license required for the Service Health feature itself.

**What should I do if an incident is not listed in Service Health?**

If you are experiencing a problem that is not shown in Service Health, it is likely a local issue. Start troubleshooting your own network, devices, configurations, or licensing. If the issue persists and you suspect a Microsoft error, open a support ticket.

**Can I set up custom notifications for specific services only?**

Yes, in the Microsoft 365 admin center Service Health settings, you can choose which services you want to receive notifications for. For Azure, you create separate alert rules per service or incident type.

**Is Service Health data available via API for integration?**

Yes, the Microsoft Graph API has a serviceAnnouncement endpoint that returns health overviews. You can use this to integrate Service Health into your own monitoring, reporting, or automation systems.

**How long is Service Health history kept?**

Standard Service Health history is available for 30 days. If you need longer retention, you must export the data (e.g., via API or CSV download) and store it yourself. Some advanced admin audit logs provide up to 90 days.

## Summary

Service Health is a vital tool for any IT professional managing Microsoft 365 or Azure services. It provides a single source of truth for the current and historical health of cloud services, distinguishing between issues caused by Microsoft and issues that are local to your environment. This saves time, reduces user frustration, and helps you communicate effectively during outages. In terms of exam preparation for MS-102, MS-900, and AZ-104, you must know how to access Service Health, interpret its status indicators (incident, advisory, maintenance), configure notifications, and integrate it via API. You should also be careful not to confuse it with Message Center, which handles planned changes. The most common mistake is not checking Service Health first when a problem arises, always make it your initial step. Service Health also supports compliance by providing post-incident reports and historical data for audits. By understanding Service Health thoroughly, you will not only pass exam questions but also become a more effective cloud administrator in real-world operations. Remember the memory trick: Service Health is your 911 for cloud, check it before you do anything else.

---

Practice questions and the full interactive page: https://courseiva.com/glossary/service-health