How It Works

This dashboard polls vendor health APIs every 5 minutes and surfaces the results in real time. Each vendor is monitored differently depending on what data is publicly available.

How data flows

1 An Azure Function App runs one timer trigger per vendor on a 5-minute schedule (plus one on startup).

2 Each trigger fetches status data from the vendor's API (or performs a synthetic availability check), maps the result to OK / Degraded / Outage / Unknown, and writes or updates a row in the SharePoint VendorStatus list.

3 A separate HTTP trigger reads the SharePoint list and returns JSON.

4 This page and the main dashboard fetch that JSON every 5 minutes and render the results.

OK — all clear

Degraded — partial outage or slow

Outage — service down

Unknown — no data yet

Vendor monitoring methods

Microsoft Microsoft Graph API

Fetches live health data directly from graph.microsoft.com/v1.0/admin/serviceAnnouncement/healthOverviews using an Entra app registration with ServiceHealth.Read.All permission. This is Microsoft's own health reporting API — the same data that appears in the Microsoft 365 admin center.

Coverage: 36 Microsoft 365 services tracked individually (Exchange Online, Teams, SharePoint, OneDrive, Entra ID, Intune, and more). Active incidents are fetched separately and attached as headlines.

Forte Statuspage API

Fetches from Forte's public Atlassian Statuspage JSON endpoint: status.forte.net/api/v2/summary.json. This returns the overall status indicator and a list of all active incidents. Covers 35 components.

Billtrust Pending

Billtrust's status page at status.billtrust.com currently requires login, so we can't read it automatically.

Billtrust monitoring is not yet active. If you find a public status URL (check past incident notification emails from Billtrust), send it to the Ops team to get this wired up.

ServiceTrade Uptrends API

ServiceTrade's status page is powered by Uptrends, which exposes a public dashboard API. Every 5 minutes, the poller queries all 17 monitored components (Core App, PartsManager, Mobile Apps, APIs, and more) and reports the worst status across all of them.

Status values: Uptrends ok → OK, unconfirmed → Degraded, error → Outage. When components are affected, the headline lists their names.

Profitzoom Synthetic check

No public status page exists for Profitzoom. Every 5 minutes we send an HTTP GET to app.profitzoom.net/pyebarker/ (the PyeBarkerFS app URL) and record the response code. HTTP 2xx = OK; 4xx/5xx or connection failure = Outage. The actual response code is always shown in the card headline.

This check confirms the app responds but won't detect degraded performance or backend errors that still return 2xx. No public status page has been found for Profitzoom.

Polling schedule

All vendor pollers run every 5 minutes on a cron schedule (0 */5 * * * *), plus one immediate invocation when the function app starts or a new version is deployed. The dashboard auto-refreshes every 5 minutes as well.

Data is stored in the SharePoint VendorStatus list on the prodops team site. The list has one row per vendor/service — rows are updated in place (upserted) each cycle, not appended.

Azure resources

Resource	Name / Details
Subscription	Pay-As-You-Go — portal.azure.com
Resource group	`rg-prodops-status` — West Central US
Function App	`prodops-vendor-status-poller` — Python 3.11, Linux Consumption, Central US
Function App logs	portal.azure.com → Function App → Monitor → Functions — click any function → Monitor tab for invocation logs
Storage account	`rgprodopsstatusa734` — West Central US, static website hosting
Dashboard URL	rgprodopsstatusa734.z19.web.core.windows.net
Entra app registration	`prodops-vendor-status-poller` — entra.microsoft.com → App registrations
Entra tenant	`pyebarkerfs.com` — entra.microsoft.com
SharePoint site	pyebarkerfs.sharepoint.com/teams/prodops
SharePoint list	`VendorStatus` — one row per vendor/service, upsert key is `Service`