Check it live. Don't take our word for it.
We don't publish uptime percentages we'd have to ask you to trust - consistent with everything else on this site. Instead: the live health endpoint, and an honest account of what fails how.
One endpoint, no dashboard in between
The edge API answers for itself. Curl it, script it, alert on it - it's the same check we run.
curl https://api.surfil.com/healthReturns JSON, and answers 503 when the edge cannot reach its database - so alerting on it works. When we add per-component probes, they'll appear here as endpoints you can hit, not as green dots we paint.
What Surfil is made of, and what breaks how
The most useful status information isn't a percentage - it's knowing what a failure of each component actually costs you. Mostly: nothing.
| Component | What it does | If it degrades |
|---|---|---|
| On-device runtime | Interception, pipeline, Weave, local buffer | Keeps working offline - nothing depends on the network to intercept |
| Edge API (api.surfil.com) | Auth, entitlement, ingest, metering, signing | Signed batches buffer on-device and replay - no value is lost |
| Signing service | Ed25519 signatures on every paid output | Fail-closed: no signature, no Credit consumed |
| Hub dashboard | Account, billing, metadata-only dashboards | Read surface only - agents and receipts are unaffected |
| Datastores (D1 · Postgres · R2) | Entitlement, identity, ciphertext memory, evidence | Receipts already issued keep verifying offline |
Built so an edge outage is boring
The device does the heavy work; the edge is stateless. That split is also the availability story.
Local buffer, always
Signed batches queue on-device during any edge incident and replay when the signal returns. No signed value is ever lost to an outage.
Fail-closed where it counts
Security paths fail closed: if the signing service can't sign, no Credit is consumed and no unverifiable output is produced.
Receipts outlive incidents
Verification is offline by design. Every receipt already issued keeps verifying during - and after - any outage, ours included.
How we'll report incidents
There is no incident history to show yet - Surfil is early and we won't fabricate one to look established. Here's the standing policy for when it exists.
Dated and specific
Every incident gets a timestamped entry: what degraded, for how long, what the measured impact was.
Impact in your terms
We report what it meant for you - buffered batches, delayed receipts - not vague “some users experienced issues”.
Post-incident, in the open
Root cause and the fix land in the changelog, same as any other shipped change.
security@surfil.com - see the security page for the reporting process.Wire the health check into your own monitoring
The endpoint is public and unauthenticated by design. If you want to be paged before we email you, you can be.