Status
Live state of the platform and the third parties it depends on.
Checked Sun, 27 Sep 2026 04:21:49 GMT. Build 06b1b44, version 0.1.0, uptime 0s.
Platform components
| Component | Status | Latency | Note |
|---|---|---|---|
| Database | healthy | 311 ms | — |
| Authentication | healthy | — | — |
| rateLimiter | degraded | — | in-memory fallback — set UPSTASH_REDIS_REST_URL + UPSTASH_REDIS_REST_TOKEN for multi-instance safety |
| llm | healthy | — | ANTHROPIC_API_KEY present |
Audit ledger
The SHA-256 hash-chained audit ledger is the regulator-defensible spine of the platform. This panel surfaces the live chain head and a sampled-row verification. The probe at /api/health/ledger replays a bounded tail of the chain on every call; the row count it actually walked is below, rather than restated here where it could drift from the probe. A verified result covers those rows only: it says none of them has been edited or reordered, and it says nothing about whether new rows are still being written — that is what the entry age below is for.
7023586eb2229f73…457b6f86672558f2All 200 sampled rows reproduced their SHA-256 chain links. This covers the sampled tail only, and says nothing about whether new rows are still being written — see latestAgeSeconds.
Upstream dependencies
Circuit breakers around each external dependency. OPEN means we’ve detected sustained failures and short-circuited calls to that dep (falling back to deterministic heuristics where applicable); HALF_OPEN means we’re probing for recovery. Probe at /api/health/breakers.
The breaker probe did not respond, so this page cannot say what state the dependency breakers are in.
Subprocessor status
Each vendor publishes its own status. We don’t aggregate their pages live (no scraping), but if you’re triaging a degradation these are the canonical destinations. Full subprocessor list with regions and DPA links is at /legal/subprocessors.
| Vendor | Purpose | Status page |
|---|---|---|
| Supabase | Primary database; row-level data store | status.supabase.com |
| Clerk | Authentication (SSO, MFA, session management) | status.clerk.com |
| Sentry | Error / exception monitoring | status.sentry.io |
| Better Stack | Logs + uptime monitoring + status page | status.betterstack.com |
| GitHub (Actions, repository) | Source control + CI/CD | www.githubstatus.com |
| Anthropic | AI / LLM-backed features (analysis, narrative generation) | status.anthropic.com |
| OpenAI | Text embeddings for agent retrieval | status.openai.com |
Service-level objectives
- API uptime: 99.5% target (measured monthly, excluding scheduled maintenance announced ≥7 days in advance).
- p95 API latency: <500 ms for read endpoints, <2 s for AI-backed endpoints.
- Incident-response initial acknowledgement: within 15 minutes during business hours; within 1 hour out-of-hours. See INCIDENT_RESPONSE.md.
- Backup recovery point: ≤24 h (Supabase daily backups). Restore drills documented at BACKUP_RESTORE.md.
Past incidents
No customer-affecting incidents in the last 30 days. Material incidents are posted here with description, root cause, customer impact, and remediation timeline. Customers with a signed DPA receive direct notification per clause 9 of the DPA (within 24 hours of the platform becoming aware).
This page reflects in-app health checks and is updated on every request. For independent uptime monitoring, prospective customers can configure their own probe against /api/health.