Shotium Status

Public status page for Shotium — live at status.shotium.com.

How it works

• Probes — GitHub Actions scheduled checks (Uptime CI; the cron is */5, but GitHub throttles scheduled workflows on low-activity repositories, so in practice a probe lands roughly every 3 hours — minute-level alerting lives in a separate private probe, this page is the public record):
  • Website & Dashboard: https://shotium.com/api/health, expects 200 with "status":"ok" in the body
  • API: unauthenticated https://api.shotium.com/v1/screenshot, expects 401 — proving edge, routing and the auth layer are alive
• Data — every check result is committed to this repository: history/*.yml (current snapshot per service) and history/summary.json (aggregates, including daily downtime minutes). Uptime CI commits on status changes; Response Time CI forces a daily snapshot so aggregates never go stale. Fully auditable via git history.
• Incidents — downtime automatically opens a GitHub Issue labeled status; closing the issue marks recovery. Blips that auto-recover within 15 minutes are treated as probe noise and pruned (Upptime default).
• Site — site/ is a custom Nuxt static build deployed to GitHub Pages by Static Site CI (daily rebuild, plus an immediate rebuild when a status flips). Data is baked in at build time; current status refreshes at runtime from raw committed JSON.

Keeping chrome in sync

The header and footer (site/app/components/SiteHeader.vue / SiteFooter.vue) are ports of the main site's chrome (shotium repo, app/components/). Whenever the main site's header/footer changes — nav items, footer link columns, tagline, brand lockup — mirror the change here (links become absolute https://shotium.com/...; no session state on this site) and push: only a push to master triggers Static Site CI, a local commit alone never reaches production.

Monitoring engine by Upptime (pinned version, template auto-updates disabled). The UI is our own.

License

MIT