Symptom: the editor spins. Cause: maybe DNS, maybe a CDN edge, maybe an API quota, maybe a true outage. Collapsing all of that into “the site is down” wastes an afternoon. This note is a small reading order for black-box checks—the kind of floor telemetry you can glance at before you rewrite scripts.
I use getstatus.ai as that glance layer: per-service pages with TCP/TLS (and HTTP when available), response trends, and incident context for the tools in a normal builder workflow.
| Layer | Question it answers | False confidence risk |
|---|---|---|
| TCP :443 | Can we open a socket? | CDN/gateway up ≠ app healthy |
| TLS handshake | Cert path + secure session? | Still may be a parking page |
| HTTP status / latency | Did an HTTP probe succeed, and how slow? | Feature APIs may differ from homepage |
| Community reports | Are many people seeing the same pain? | Reports ≠ confirmed outage alone |
Google SRE’s chapter on monitoring distributed systems frames the same idea: separate what’s broken (symptom) from why (cause), and prefer black-box signals when you care about user-visible failure.
For platform-root checks (account portal, API docs host, billing), I keep OpenAI status bookmarked beside product UIs. Sibling surfaces fail on different cadences than chat UIs. When the workflow spans multiple models, a single green light is not enough. I compare the same window on Gemini status—especially when HTTP probes are unconfirmed while TCP/TLS still pass. That pattern is a classic “edge up, app unclear” case, not proof that your laptop is broken.
For broader internet-scale corroboration (country/ASN outages, not app features), Cloudflare documents how Radar tracks disruptions in Outages · Cloudflare Radar docs—useful background when the failure mode looks bigger than one SaaS. Ship the triage order, not vibes. If you have a tighter checklist for multi-model desks, drop it in the comments.