Suite incidents slip past a per-service filter

Symptom

Users report SharePoint (or Outlook, Teams) down; your dashboard built on /admin/serviceAnnouncement/issues shows the service as healthy with no incident.

Fix

const TRACKED = [
  { key: 'sharepoint', service: /sharepoint/i, text: /sharepoint/i },
  { key: 'exchange',   service: /exchange/i,   text: /exchange|outlook|mailbox/i },
  { key: 'teams',      service: /teams/i,      text: /\bteams\b/i },
  { key: 'onedrive',   service: /onedrive/i,   text: /onedrive/i },
  { key: 'entra',      service: /entra|azure active directory/i, text: /\bentra\b|sign[- ]?in|authenticat/i },
];

function affected(issue): string[] {
  const direct = TRACKED.find(t => t.service.test(issue.service || ''));
  if (direct) return [direct.key];
  if (!/microsoft 365 suite/i.test(issue.service || '')) return [];
  const text = [issue.title, issue.impactDescription, issue.feature, issue.featureGroup].join(' ');
  const named = TRACKED.filter(t => t.text.test(text)).map(t => t.key);
  return named.length ? named : ['sharepoint', 'exchange', 'teams', 'onedrive']; // "multiple services", none named
}

• Store one record per affected workload (e.g. MO1550821~sharepoint) so per-service history works, and merge them back into one item in the UI — otherwise one incident shows up four times.
• Keep filtering on classification eq 'incident' if you only want incidents; the suite incident above was an incident with status serviceDegradation.

Notes

• Verified 2026-11-13 on one tenant with an app-only token (ServiceHealth.Read.All): after the change, MO1550821 (status serviceDegradation, start 2026-11-12T18:26:10Z) appeared on the next 15-minute poll. It reached the data only through the suite branch, which requires service to match /microsoft 365 suite/i; the raw service string itself wasn't logged.
• Most incidents are partial ("some users", one feature) and often run for days. Don't weight them into an uptime percentage: counting them as partial downtime put Exchange at 88 % over 90 days, which read as "down for days". If you show uptime, compute it from outages only, state the definition on the page, and show days with reports separately.
• Don't rely on serviceInterruption alone to find outages. On the same tenant, none of the incidents for SharePoint, Exchange, Teams, OneDrive and Entra over 90 days (to 13 Nov 2026) had that status — even EX1550543, "Users may be unable to connect to their mailboxes in Exchange Online through multiple connection methods", was serviceDegradation, as was MO1550821. A status-only rule reports 100 % through a real outage. Counting every suite incident as an outage overshoots the other way: some run for days (mostly delays), and SharePoint dropped to 90 % over 90 days. What held up: count a suite incident as an outage only when its title or impact text says users are "unable to connect/access" (and not "some users"), and state in the definition that the duration is how long Microsoft kept the incident open.
• Polling incrementally with lastModifiedDateTime ge <last run> means a changed mapping rule never reaches old incidents. Store a rules version with your sync state and re-read the full window once when it changes.
• Before the fix, healthOverviews reported SharePoint and Teams as serviceDegradation while no incident filed under them was open (the cause wasn't isolated — likely the suite incident or advisories). Derive the per-service badge from the incidents you actually show, or the badge contradicts the incident list.