How to triage “model down” vs “workspace down” before you rewrite scripts

#devops #monitoring #status

Builders often collapse three different failures into one Slack message: AI is broken. Sometimes the model endpoint is degraded. Sometimes the knowledge base or docs host is the problem. Sometimes only your laptop’s DNS is lying. This how-to is a short reading order for black-box checks—enough to decide whether to wait, switch tool, or keep debugging locally.

I use getstatus.ai as that glance layer: per-service pages with TCP/TLS (and HTTP when available), response trends, and incident context for tools in a normal builder workflow.

A five-step triage (mental, not bash)

Note wall-clock when the failure started.
Reproduce on another network (phone tether) and a private window.
Open an independent checker and the vendor status page.
Read TCP → TLS → HTTP; do not stop at a green marketing badge.
Match your symptom to the chart window (spike vs flat healthy).

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.

Hugging Face as a “platform host” check

When the failure looks like model cards, Spaces, or inference endpoints rather than a single chat UI, I open Hugging Face status first. Platform hosts and product UIs fail on different cadences; a healthy marketing page does not prove an inference path.

Midjourney when the creative path is the blocker

If the blocked work is image generation rather than code, swap the bookmark to Midjourney status and run the same order. Queue acceptance without finished renders is a classic “edge up, app unclear” pattern—treat connection health as a floor, not a verdict.

For broader disruption context (country/ASN outages, not app features), Cloudflare documents how Radar tracks disruptions in Outages · Cloudflare Radar docs.