TTS status page: reading health before you escalate — Audra

status.audratalks.com is generated from live data — the gateway's own /health endpoint and engine routing from /v2/models, polled every 30 seconds. There is no status page operator composing prose between you and the signal. This post is how to read it and how to triage a failing render against it in under a minute.

What the page shows

• Gateway health, with the running version number — so you can correlate a behavior change with a deployment.
• Per-engine tier status for all four engines, from /v2/models routing — an engine can be degraded while the gateway is green, and the page distinguishes the two.
• 30-day uptime percentage, computed from gateway health samples, plus a 30-day daily bar chart where each bar is one day's samples. Browsers show per-day detail on hover: date, uptime percentage, sample count.
• Recent incidents — currently 'none reported'; the page covers the gateway plus all four engines, so an engine outage would appear here.

Triage: 502/503 on a render — page, or you?

The decision tree that saves an escalation: (1) Open /status. (2) If an engine tier or the gateway is red, it is us — monitor, retry with backoff, no ticket needed; incidents resolve visibly on the same page. (3) If everything is green but your request returned 5xx, it is most likely a cold start on a render container — transient, and the retry guidance at /blog/cold-start-tts-502-retry handles it in one line of code. (4) If the page is green and retries consistently fail with the same error, then it is a support conversation (hello@audratalks.com or /support), and your retry logs are the attachment.

Monitoring it without a browser

/health is a public JSON endpoint — the same one the page polls — so your uptime tooling can poll it directly on a 30-second cadence and alert on the tts engine status field or version change. The page's uptime percentage is computed only from samples since the gateway instance started, so a restart resets the window; treat the 30-day number as directional and your own /health polling as the SLA-grade record. This matters if you are wiring TTS availability into your own status page or on-call runbook: alert on engine-level status, not just gateway reachability, because degraded engines fail renders while the gateway answers 200s on /health.

Related operational posts: cold-start retry strategy at /blog/cold-start-tts-502-retry and QA-gated billing at /blog/tts-api-billing-qa-gated.