Public status page

status.platformdtc.com is live. Live operational state for the surfaces we probe, a rolling uptime record, and the full incident history — with email, Slack, Teams, webhook, RSS and Atom subscriptions. See Platform Status.

Added

• Eight components, grouped by who feels the failure: Storefronts and Checkout (buyer-facing), Merchant Dashboard and Core API (merchant), and Notifications, Background Jobs & Fulfillment, Analytics & Reporting and Documentation (platform).
• A JSON API implementing the Atlassian Statuspage v2 contract — /api/v2/summary.json, status.json, components.json, incidents.json, incidents/unresolved.json. Unauthenticated, CORS-open, cached 30s. Any existing Statuspage widget or uptime aggregator works against it with no adapter.
• Response times, not just up/down. Every component publishes its p50, p95 and the tail ratio between them, alongside the exact thresholds we alert on. If you think a surface is slow you can cite the same number we do.
• GET /api/v2/uptime.json — 90-day daily uptime history. A PlatformDTC extension; Statuspage keeps this private.
• Signed webhooks using the same X-PlatformDTC-Signature HMAC-SHA256 scheme as platform webhooks, so existing verification code works unchanged.

Notes

• The page has no origin server. It runs entirely on Cloudflare's edge and shares no infrastructure with the systems it reports on, and its checks run from outside our network. A status page hosted on the thing it monitors goes dark exactly when you need it, so this one is verified the hard way: by cutting off every monitored service and confirming the page still loads and correctly reports a major outage.
• Alerting keys on the tail, not the average. An internal investigation found individual API requests reaching 9.9s while the median held at a healthy 0.31s — every average-based dashboard was green for weeks. Thresholds are per-component because healthy baselines span two orders of magnitude across these surfaces, from ~12ms on cached checkout to ~1s on the server-rendered dashboard.
• Feeds and webhooks emit one entry per incident update, not per incident, so subscribers hear about progress and resolution rather than only the opening.
• Email is double opt-in. An unconfirmed address is never sent anything.
• Individual stores are not modelled. Problems affecting a small number of specific stores may not appear — this reports platform-wide state. If your store is affected while the page is green, contact support rather than assuming it is you.