Liveness check
The canonical liveness endpoint is /api/health. It returns an explicit JSON shape with a database round-trip result and a build identifier — useful for uptime monitors, incident response, and tooling. Cache headers are no-store, so every call is fresh.
Response shape:
{
"ok": true,
"service": "shotshq",
"version": "<sha-or-package-version>",
"env": "production" | "preview" | "development",
"checks": { "db": { "ok": true, "latencyMs": <ms> } },
"latencyMs": <total-ms>,
"ts": "<iso8601>"
}Incident communication
Pre-launch we don't publish a live status board. If something is broken, we post it in the changelog and, for sustained outages, on the /under-construction surface that fronts the site during maintenance windows. A third-party status page (Statuspage / Better Stack) is in scope for v1.1.
Reporting an issue
Email support@shotshq.com with the URL you were on, a screenshot, and the timestamp. The Sentry trace ID from the page footer (if present) speeds triage materially.
This page intentionally shows no real-time metrics. ShotsHQ is pre-launch and we don't fabricate p50 latencies or queue depth — when a real status board ships, it'll be backed by the health endpoint above, not by hard-coded numbers.