Status Page Transparency Report
We read the status pages of 2,463 vendors every minute, so we can count what they actually publish rather than what they promise. Two things stand out: 73.3% run the same product (Atlassian Statuspage), and 73.2% never tell you which region is affected.
As of September 27, 2026 · 2,463 active services · 135,263 components · Counted, not sampled
The concentration problem
73.3% of the vendors we track publish through Atlassian Statuspage. Status reporting for most of the industry therefore depends on one company staying up. That is a real single point of failure, and it is the sort of thing that only becomes obvious when someone counts.
The regional gap is the more practical problem day to day. 2,327 providers (96.5%) will tell you which component is broken, but only 645 (26.8%) will tell you where. For anyone running in a single region, “degraded” from the other three quarters is an unanswerable question.
Only 10 vendors (0.4%) publish no machine-readable status page at all. Publishing something is now close to universal. The variation is almost entirely in how much detail it carries.
What vendors run their status page on
Counted per service. Atlassian Statuspage is the most common at 73.3%. “Self-built” means the vendor wrote their own page rather than buying a hosted product, usually the hardest to parse and the least consistent between vendors.
How much detail they actually publish
Counted per provider, not per service. Components belong to providers, and several services can map to one provider. 2,411 providers publish at least one component; 135,263 components in total.
| Measure | Providers | Share |
|---|---|---|
| Break status down by component | 2,327 | 96.5% |
| Publish one global signal only | 84 | 3.5% |
| Report per region | 645 | 26.8% |
Median components per provider: 11 · Deepest breakdown: 34,319 components. The median is a true median, not a mean: a handful of hyperscalers publish thousands of components each and would drag an average into meaninglessness.
Full breakdown by status-page type
The raw counts behind the grouping above, so the grouping can be checked rather than taken on trust.
| Detected type | Grouped as | Services |
|---|---|---|
| STATUSPAGE_JSON | Atlassian Statuspage | 1,806 |
| BETTERSTACK | Better Stack | 308 |
| INSTATUS | Instatus | 104 |
| STATUS_IO | Status.io | 53 |
| STATUSPAL | StatusPal | 29 |
| ROOTLY_STATUS | Other hosted platform | 19 |
| STATUSCAST | StatusCast | 19 |
| HYPERPING | Other hosted platform | 14 |
| M365_CUSTOM | Self-built status page | 13 |
| GENERIC_CUSTOM_HTML | Self-built status page | 12 |
| GENERIC_CUSTOM_JSON | Self-built status page | 11 |
| DIRECT_HEALTH_CHECK | No status page published | 10 |
| FIREHYDRANT_STATUS | FireHydrant | 7 |
| SALESFORCE_PRODUCT_INSTANCES | Hyperscaler health API | 4 |
| INCIDENT_IO | incident.io | 4 |
| SORRY_STATUS | Other hosted platform | 3 |
| AWS_S3_HEALTH_JSON | Hyperscaler health API | 3 |
| GCP_HEALTH | Hyperscaler health API | 2 |
| SAP_CLOUD_STATUS | Hyperscaler health API | 1 |
| BINANCE_CUSTOM | Self-built status page | 1 |
| SENDBIRD_STATUS | Self-built status page | 1 |
| WEBEX_CUSTOM | Self-built status page | 1 |
| CHECKLY_STATUS | Other hosted platform | 1 |
| STATUSCAKE_PUBLIC_REPORT | StatusCake | 1 |
| DOCKER_STATUS_IO | Status.io | 1 |
| MAILCHIMP_STATUSCAKE | StatusCake | 1 |
| OCI_HEALTH | Hyperscaler health API | 1 |
| SLACK_CUSTOM | Self-built status page | 1 |
| COREWEAVE_CUSTOM | Self-built status page | 1 |
| NAMECHEAP_STATUS_BLOG | Self-built status page | 1 |
| OKTA_TRUST | Hyperscaler health API | 1 |
| HTML_CUSTOM | Self-built status page | 1 |
| OVHCLOUD_STATUS | Self-built status page | 1 |
| DEEPL_CUSTOM | Self-built status page | 1 |
| ONELOGIN_OLSTATUS | Other hosted platform | 1 |
| ZOHO_CUSTOM | Self-built status page | 1 |
| HETZNER_STATUS | Self-built status page | 1 |
| AZURE_HEALTH | Hyperscaler health API | 1 |
| CLICKUP_CUSTOM | Self-built status page | 1 |
| UPTIMEROBOT_PUBLIC | Other hosted platform | 1 |
| NEON_CUSTOM | Self-built status page | 1 |
| GOOGLE_WORKSPACE | Hyperscaler health API | 1 |
| ZENDESK_CUSTOM | Self-built status page | 1 |
| DOCUSIGN_CUSTOM | Self-built status page | 1 |
| MOLLIE_CUSTOM | Self-built status page | 1 |
| FRESHWORKS_STATUS | Self-built status page | 1 |
| PAYPAL_CUSTOM | Self-built status page | 1 |
| PAGERDUTY_STATUS_PAGE | PagerDuty | 1 |
| XBOX_LIVE | Self-built status page | 1 |
| STATUSHUB | Other hosted platform | 1 |
| PLAYSTATION_NETWORK | Self-built status page | 1 |
| RACKSPACE_CUSTOM | Self-built status page | 1 |
| STATPING | Other hosted platform | 1 |
| IBM_CLOUD | Hyperscaler health API | 1 |
| HUBSPOT_CUSTOM | Self-built status page | 1 |
| SALESFORCE_TRUST | Hyperscaler health API | 1 |
| DATABRICKS_CUSTOM | Self-built status page | 1 |
| FIREBASE_STATUS | Hyperscaler health API | 1 |
| FASTLY_CUSTOM | Self-built status page | 1 |
| META_STATUS | Self-built status page | 1 |
Methodology
Population. Every active service in the PulsAPI catalog as of September 27, 2026, 2,463 of them. This is a full count, not a sample, so there is no margin of error to quote. It is not a random sample of the internet either: it is the set of vendors PulsAPI has been asked to monitor, which skews toward infrastructure, developer tools, and SaaS.
Two units. Platform and status-page figures count services. Component and region figures count providers, because components belong to providers and the service-to-provider mapping is alias-aware. The two are reported separately and should not be added.
“Publishes no status page” means we found no machine-readable status page for the vendor and fall back to checking the service directly. A vendor may still post incidents somewhere we cannot parse: a blog, a support portal, or a social account. This measures published, machine-readable status, not whether a vendor communicates at all.
Detection. The platform for each vendor is detected from the shape of its status feed, and it can be wrong. A vendor migrating between platforms, or running a compatibility shim in front of a different product, may be classified by the shim rather than the underlying system. The full per-type table above exists so those cases are visible.
What this is not. This report describes what vendors publish, not how reliable they are and not whether they are honest. A vendor with one global signal is not necessarily hiding anything, and a vendor with 400 components is not necessarily more trustworthy.
Corrections. If your organisation is classified incorrectly, write to research@pulsapi.com and we will recheck the detection and correct the record.
See what your own vendors publish
PulsAPI reads all of these status pages so you do not have to, and tells you when one of them changes.
More from PulsAPI Research · Cloud SLA Benchmark 2026