Availability
When Cosignet is unavailable
Cosignet sits in front of critical actions, so you should plan for the day it is slow or down before you integrate. This page describes exactly what failure looks like, what your code should do, and how to handle emergencies without silently weakening your own controls.
The principle: fail closed
If your system cannot obtain a signed approval, the gated action must not run. Unavailability must never degrade into auto-approval. This is not a limitation we apologize for; it is the entire point of an approval gate. A gate that opens when the guard is absent is not a gate.
What unavailability looks like to your code
There are only three places Cosignet touches your flow, and each has one failure mode:
- Creating an approval request (
POST /api/confirmationsor the MCP tool): network error, timeout, or 5xx. The request was not registered; nothing exists to approve. - Waiting for a decision (polling GET, or webhook): timeouts or no webhook. The request may still be pending, or our side may be degraded.
- Reading the decision: unreachable or 5xx. A decision may exist but you cannot see it yet.
What your integration must do
Treat every one of these as "not approved". Concretely:
| Signal | Meaning | Your action |
|---|---|---|
status: approved (signature verifies) | Human approved this exact payload | Proceed |
status: rejected | Human rejected | Do not run; surface to requester |
status: expired | Nobody decided in time | Do not run; re-request if still needed |
| Timeout, network error, or 5xx | Unknown state | Do not run; retry with backoff; alert after N failures |
Implementation notes
- Distinguish "rejected" from "unavailable" in your logs and alerts. One is a human decision, the other is an operational condition; conflating them hides outages and erodes trust in the gate.
- Retry reads with exponential backoff and jitter; cap total wait at your action's own deadline, then treat as expired.
- Make gated actions idempotent on your side, so a retry after an unclear state cannot double-execute.
- Never cache an approval for reuse. A signed decision is bound to one payload hash; treat it as single-use.
Emergencies: break-glass belongs to you
If Cosignet is down and you genuinely must act, the answer is not a hidden code path that skips the check. It is a documented, human-owned override on your side. We recommend, and use ourselves:
- A separate break-glass runbook: who may invoke it (at least two named people agreeing), for which actions, and for how long (time-boxed, e.g. 60 minutes).
- An explicit switch (config flag or environment variable) that is off by default, alarms loudly when on, and cannot be enabled by the automation itself.
- Mandatory logging: every action executed under break-glass is recorded with who, what, why.
- A post-incident review: every break-glass use is reviewed afterwards, and the gate is restored.
This keeps the emergency path attributable and auditable, which is the same property Cosignet gives you in normal operation.
What we do on our side
- We publish live component status and incident history at status.cosignet.com, with postmortems for anything over 30 minutes.
- Already-issued approvals remain independently verifiable from the transparency log and open-source verifiers even if our app is unreachable.
- We run Cosignet in front of our own deploys and destructive operations, so we feel outages exactly the way you do.
Current posture, honestly
Cosignet is an early product run by its founder. There is no formal SLA on self-serve plans yet; Enterprise agreements can include one. The service runs on Cloudflare's edge and inherits its availability characteristics. We will publish uptime history rather than promises: see the status page.
If your risk model needs guarantees we do not yet offer, tell us what they are: contact@cosignet.com.