Live health
Obelisk exposes a real health endpoint at /healthz. It's what our own watchdog and any external monitor probe. We deliberately don't paint a fake live-uptime percentage here — we'd rather tell you exactly how the system is built to stay up and recover.
Serving release proof
The serving process identifies the exact code revision below. This is deploy-stamped evidence, not a hand-maintained version label.
| Evidence | Serving value |
|---|---|
| Revision | 74791feb2fce315560520dff86e0de9ab7e879da |
| Deployed at |
Cross-check the same proof in /healthz response headers or the machine-readable changelog.
Recovery targets
Obelisk is designed for fast disaster recovery rather than the cost of a permanently-running hot standby. The targets below are objectives; the right-hand column shows only what this server has measured, read from its own records when this page was served.
| Objective | Target | Measured on this server |
|---|---|---|
| RTO — time to restore service after total loss | ~15 minutes | Not yet measured — no restore drill is on record on this server |
| RPO — maximum data at risk | ≤ 1 day: if the server were lost, at most about a day of changes could be lost (tighter with a more frequent backup timer) | Newest verified off-box copy: |
Recovering from the loss of the whole host means installing the service on a clean host, restoring the newest verified off-box backup — restore checks every file's hash and refuses a tampered or corrupt backup — and moving traffic to the new host.
How availability is protected
- Daily encrypted off-box backups to Cloudflare R2. A daily job bundles the service's state directory — identity records and database, receipt ledgers, the issuance log, client, organization and founder records, and signing keys — together with its configuration, passphrase-encrypts it (PBKDF2 + AES-256-GCM) with an integrity-checked manifest, uploads it to Cloudflare R2, and reads it back to confirm the stored copy matches. Restore verifies every file's hash and refuses a tampered or corrupt backup — it fails closed. The newest verified off-box copy on record was completed at .
- Health watchdog. A one-minute timer on the host probes
/healthzand restarts a wedged or crashed process without a human in the loop. It does not yet report its own liveness off-box, so a failure of the watchdog itself would not be noticed automatically. - Host-level safeguards. Whole-box snapshots, delete and rebuild protection, and an address that can move to a rebuilt host without a DNS change are recovery targets. This server cannot measure them, so we don't claim them as in place.
- External monitoring. An independent, always-on uptime monitor watching
/healthzis a target, not something we claim today./healthzis public, so your own monitor can watch it now.
Verifiable transparency
Security-relevant events in Obelisk are written to append-only, hash-chained ledgers, and the latest head of those ledgers is anchored, published and ES256-signed. Unlike Certificate Transparency, the anchors form a simple hash chain rather than an RFC 9162 Merkle tree, so there are no consistency proofs between heads yet.
What you can check today, without an account
- Save the signed ledger head, and compare it later. Fetch
/.well-known/obelisk-transparency.jsonand keep itsheadAnchorHashandanchorCount. On any later fetch the count must never go down, and while the count is the one you saved, the head must not change. A break in either rule is evidence the record was cut short or replaced. - Check that the head was signed with our key. The document's
sthfield is an ES256 signature over the head. Verify it against our published keys at/.well-known/jwks.json; the head check on the Verify it yourself page does this in your browser. - Check that a receipt you hold is in the ledger. Paste its hash into the receipt check on the Verify it yourself page. Your browser recomputes the Merkle proof from
/api/proof/<hash>, and a match shows the receipt is in the ledger we serve today. The check searches the receipts ledger; sign-in records are kept in a separate ledger it doesn't search. - Check a token we issued. Verify an ID or access token's ES256 signature with any JWT library against
/.well-known/jwks.json. Once you have the keys, that check needs nothing more from us.
What those checks can't show yet
- That a later head extends the one you saved. We don't publish consistency proofs between heads, and we don't serve past heads, so comparing heads catches a history that was cut short or replaced, not one that was rewritten and then extended with new entries.
- That a receipt check is covered by the signature. The root a receipt proof is checked against is computed by us when you ask and arrives in the same response. It isn't part of the signed head yet.
- That our keys and our records are honest. You fetch the signed head and the keys that verify it from us, so a valid signature shows the head was signed with the key we publish, not that what it describes is complete.
- That nothing happened without a record. The ledgers show what the service recorded, not what it didn't. Sign-in records are written on a best-effort basis, so a failed write doesn't block a sign-in.
- That someone outside holds the same head. No off-box copy of this head is currently verified. Until one is, the copy you save is the outside record: save
headAnchorHashandanchorCountnow and compare them on every later fetch.
| Ledger | Entries | Head |
|---|---|---|
receipts.jsonl | 8335 | 92b56345205fe106… |
issuance.jsonl | 63 | 3e35b013a94ddfa6… |
grant-usage.jsonl | 1 | 2bbc4a02dfcac95b… |
usage.jsonl | 3 | c82f9cd05647bcd0… |
Head 3d8b47b6e10802aa… · 630 anchors · anchored 2026-10-30T02:56:35.108Z
Run these checks in your browser on Verify it yourself: fetch the head and check its signature, compare it with a head you saved, and recompute any receipt's inclusion proof.
Current limits
Obelisk runs on one server. If that server is lost, the plan is to rebuild on a new one from the newest verified backup, with a target of about 15 minutes. A complete rebuild has not been timed end to end yet, so treat that figure as a target; the table above shows what has been measured. Each deploy restarts the service, and sign-ins can fail until it is back up and the proxy in front of it has noticed. A second server, which an availability SLA would need, isn't built yet, so we don't offer an availability SLA today.
Need an availability SLA or a specific data-residency arrangement? Talk to us — we'll tell you plainly what we can commit to today.