A status page that can’t go red isn’t a status page.

Register verified

22 September 2026

Live monitoring

Not yet in place

Maintenance

By hand · last reviewed 22 September 2026

We are not measuring uptime yet, so we are not reporting it.

Demonstrated

Produced an artefact end to end, in a real organisation.

Connected

Receives and records, but cannot carry attribution by construction.

Supported

Built and connected. Not demonstrated end to end by us.

Beta · untested

Built to the documented contract, never validated end to end by us.

Signal only

Seals a signal receipt without field-level classification.

Not read yet

Connects and receives, but nothing it sends is read into attribution yet.

This register is maintained by hand; the date above is the last review. A row moves up only when something has been demonstrated end to end — rows have moved down before, and will again.

What is watching, and what isn’t yet.

The distinction that matters to a security review is not whether monitoring exists, but whether the absence of an alert means anything. 3 of 7 rows below are in place.

• In place

  Ledger integrity is enforced, not monitored

  The append-only constraint is enforced at the database layer rather than checked periodically. It doesn't need a health check to be true, and an auditor can read the constraint definition themselves.

• In place

  Receipt issuance is self-evidencing

  If receipts stop being issued, your ledger stops advancing and you can see that directly. This is the one component where the product is its own monitor.

• In place

  Rejected deliveries carry a disposition

  Inbound webhooks that fail signature verification, arrive from an unknown source or carry a payload we cannot parse are recorded with their rejection class rather than dropped silently.

• Not yet

  Independent synthetic monitoring

  No external prober is confirming that the ingestion path, the console and the verifier distribution are reachable right now. Until that exists, this page cannot tell you whether Déjà is up — only what it is designed to do when it is.

• Not yet

  Per-connector health checks

  A connector's standing above reflects what we have demonstrated, not a live signal. A source that quietly stops delivering is something you would notice before we would, which is exactly the gap being closed first.

• Not yet

  Automated incident detection and notification

  Detection is manual. Notification delivery is not built, and we publish no sign-up form rather than collect addresses we could not notify.

• Not yet

  Measured uptime and latency

  No p50, p95 or p99 figures, and no uptime percentage, because there is no measurement behind them. Engineering targets exist internally; they are not results and we won't publish them as though they were.

The record starts today, not backwards.

We are not publishing a clean ninety-day history, because we were not measuring for most of it and a green grid asserting otherwise would be the kind of artefact this company exists to argue against.

Operational summary, at a glance.

Detail and dependencies live on the security page, which states what each claim rests on. Short version:

Active

Append-only ledger

Delete and truncate are rejected by database triggers on every receipt table, below the application layer, and update is rejected except to record a review decision or fill an empty link or hash once. A change to a signed field breaks its signature.

Active

Receipt signing

Signed receipt types carry a signature at issuance — Ed25519 on Déjà's managed key, RSA-PSS or ECDSA on a vault's own KMS key; sealed types carry a content hash. Bundles state which applies per receipt.

Active

Tenant isolation

Row-level policies keep each vault's data apart. One vault, one ledger. Déjà-managed vaults share one signing key; a vault on its own KMS key has its own.

In progress

SOC 2

Type I in preparation, Type II following its observation window.

In progress

Independent penetration test

Engagement underway. We will name the firm and the date when there is a report to name them on.

Active

Outside time-stamp on ledger checkpoints

A receipt's issue time comes from Déjà's own clock. What an outside party vouches for comes later: about once a day a company's new receipts go into a signed ledger checkpoint, which DigiCert's public time-stamp authority (RFC 3161) then stamps. That proves a receipt existed by the stamped time, not when it was issued.

Why this page reads the way it does. Déjà’s product is the difference between “we found nothing” and “we couldn’t look.” Applying that standard to our own operations means saying which one we’re in, on every row, including the rows where the answer is unflattering. A status page is the easiest place in a company to quietly stop doing that.

Something here wrong, or out of date?

This register is maintained by hand, which means it can be stale in a way an automated page can’t. If you find a row that doesn’t match what you’re seeing, tell us — corrections are published here with the date they were wrong from.

This page is maintained manually and reflects what Déjà has demonstrated, not live measurement. It is not a service-level commitment; contractual availability terms, where they exist, are set out in the customer agreement. “Sealed” means written into an append-only chain with a content hash when the receipt is issued; “signed” is used only where a receipt additionally carries a signature — Ed25519 on Déjà's managed key, RSA-PSS or ECDSA on a vault's own KMS key — and every bundle states which applies per receipt. A receipt's issue time comes from Déjà's own clock. What an outside party vouches for comes later: about once a day a company's new receipts go into a signed ledger checkpoint, which DigiCert's public time-stamp authority (RFC 3161) then stamps. That proves a receipt existed by the stamped time, not when it was issued.