Spire Coast · Uptime
Where we host. What we monitor. How we tell you.
We run a small but boring stack on purpose. Boring stacks have fewer outages. When they do go down, we tell you fast.
Last updated · May 2026
Status
All systems normal.
Live status reflects synthetic monitors against the public surface. We’re wiring up a public status page on status.spirecoast.com; until it ships, this card carries the live signal and any open incident.
Last 30 days
100.00%
No incidents recorded since launch.
§ 01 · Where it runs
Four providers, no surprises.
Apps & sites
Target 99.99%
Vercel Pro
Marketing sites, client websites, and the portal run on Vercel’s edge network. SLA inherits Vercel’s 99.99% target. Region: Washington, D.C. (us-east-1).
Background work
Target 99.9%
Hetzner CX22
n8n, Postgres, and Langfuse run on a Hetzner CX22 in Ashburn, Virginia (US-East). A second CX22 in Falkenstein, Germany serves as the disaster-recovery target.
Database
Target 99.95%
Neon serverless Postgres
Content, portal, and RAG databases each live in their own logical Neon database. Point-in-time recovery, branched dev databases, encrypted at rest.
DNS & CDN
Target 100%
Cloudflare
DNS and edge caching at Cloudflare. R2 holds off-site backups. The free tier handles every site we run today, with paid tiers reserved for client traffic that needs them.
§ 02 · How we communicate during an incident
Fast, written, and honest about what we don’t know yet.
Step 01
Detection.
Synthetic monitors run every 60 seconds against the public site. Internal services emit health metrics to Langfuse. PagerDuty is wired to the founder’s phone for sev-1.
Step 02
First update.
Every incident gets a public note within fifteen minutes. We say what we know and what we don’t. We don’t wait for a clean explanation to acknowledge a problem.
Step 03
Updates while it’s open.
Every thirty minutes during a sev-1, every hour during a sev-2, until resolved. Affected clients get a direct email at the same cadence.
Step 04
Postmortem.
Every sev-1 gets a public postmortem within seven days: timeline, root cause, what we changed. Posted on labs.spirecoast.com so the whole studio learns from it.
§ 03 · Disaster recovery
Practiced once a quarter.
Backups run nightly to Cloudflare R2 in a region separate from the primary database. Postgres runs point-in-time recovery for any rollback inside the last seven days.
We rehearse a full restore once a quarter against the Hetzner Falkenstein DR target. The drill measures recovery time (target: under four hours for a complete rebuild) and confirms the runbook still works without the founder logged in to anything personal.
The full DR runbook lives in our internal Notion. A redacted version is shared with any client whose SOW asks for it.
§ 04 · Get notified
Subscribe to the status page.
The public status page at status.spirecoast.com is wiring up alongside Phase 5. Once it ships, you’ll be able to subscribe by email or RSS. Until then, active clients get incident emails directly.