Status
Availability, honestly reported.
This page is maintained by hand; the date below is the last recorded incident-history review, not a live availability check. It is not automated probing, and it does not display a live health indicator — a status light that cannot turn red during an outage would be worse than no status page at all.
Incident history
Last reviewed . This does not establish availability or the absence of incidents after that date. An empty history is not a reliability record.
What happens when INTYGA is unavailable
Approvals stop. Actions waiting on one do not proceed. This is deliberate: a gate that opens when the vendor is unreachable is not a gate, and for an operation you cannot undo, refusing is the correct failure.
Concretely, the SDK surfaces an error or an expired status — never an approval. An outage therefore delays a gated action rather than releasing it unapproved.
What keeps working
- Receipt verification runs inside your runtime against trusted approver keys, without contacting us. Unexpired, unused approvals can still authorize their exact action during an outage. Retained receipts remain independently checkable as historical evidence; expiry and single-use rules still prevent an old receipt from authorizing a new action.
- Approving a new action, via Offline Approval. Your own service builds the challenge, your approvers sign it on a device with no connectivity, and your runtime verifies the result with the same check it always runs. INTYGA is not in the loop.
- Anything not behind a gate. INTYGA sits in front of the specific actions you chose to govern, not in front of your application.
- Previously issued evidence. Anchored checkpoint roots are held by independent transparency logs, not only by us.
Offline Approval
The obvious way to survive an outage is to pre-sign approvals for actions you expect to need and hold them until something breaks. We specify that approach as NOT RECOMMENDED, and we do not ship it. A pre-signed proof is a bearer capability sitting in a file: possessing it is enough to act, it cannot be revoked at a relying party that is offline, and the human signed off on a hypothetical rather than on the incident actually in front of them. Narrowing what it authorizes does not fix that, because the defect is in when the person decided.
Offline Approval moves the signing ceremony off the network instead of earlier in time. At incident time your relying party generates the nonce and builds the challenge itself; approvers review and sign it on a disconnected device; your runtime verifies the result through the ordinary procedure. Nothing sitting at rest authorizes anything, and the approvers are looking at the real incident. The validity window is bounded in minutes — implementations cap it at 60 — so a proof minted with an over-long expiry is rejected even when its signature is valid.
For the narrower case where your approvers are also unreachable, a Delegation transfers the authority to approve to named local operators for a bounded period. A Delegation authorizes no action by itself: verification refuses that payload type unconditionally, and there is deliberately no flag that lets one through. It is an input to a later approval check, never a substitute for one.
How to report an outage
Email us with the approximate time, the workspace, and what you observed. If you believe the cause is a security issue rather than an availability one, use the vulnerability disclosure process instead — it is monitored more aggressively.