What we run, and what we will not claim about it

Enclessa is one multi-tenant installation in a single European Union region, operated by a German company, with every customer organisation reachable at its own subdomain. There is no choice of country within the region on the standard plans, and no custom domains.

• One European Union region, one installation, many customer organisations
• The application, the realtime gateway and the public site run behind a shared edge proxy
• The database, the message layer, the object store and the media server each run as a single instance pinned to one node
• The application and gateway processes run with more than one replica, so a single process failing is not an outage
• An organisation that needs a named country buys a dedicated deployment under Enterprise, operated by us

Every service exposes two separate checks rather than one, and the difference between them is what makes a rolling deployment safe. `/healthz` answers whether the process is alive; `/readyz` answers whether the things it depends on are reachable. The orchestrator restarts on the first and the edge proxy routes on the second, so an instance that is running but cannot reach the database stops receiving traffic instead of failing requests.

• The edge proxy routes only to instances whose readiness check passes, re-checked continuously
• The orchestrator restarts a process whose liveness check fails
• Database migrations are backward compatible across exactly one version, so old and new processes can run against the same schema during an update
• The application refuses to start against a schema that is too old, and accepts one that is newer
• Configuration is validated before start-up, and unsafe combinations are refused rather than logged

An incident is defined by what a customer can observe, not by what an internal dashboard shows. A saturated queue that nobody notices is an engineering problem; a message that does not arrive is an incident. Enclessa uses three levels, and the level decides how quickly somebody is told rather than how urgently it is worked on — everything below is worked on immediately.

• Major — the service is unusable for a substantial share of organisations: sign-in fails, messages do not send, or the application does not load
• Partial — one capability is unavailable or materially degraded while the rest works: calls fail to connect, uploads are refused, search returns nothing, or notifications are not delivered
• Maintenance — a planned change with expected customer-visible effect, which is announced ahead of time rather than reported afterwards
• A security incident affecting personal data is handled separately and to a statutory timetable, and is described on the trust centre rather than here
• Degraded performance that does not stop work is not an incident and is not reported as one

Until a public status endpoint exists, communication is direct rather than broadcast. That is a smaller promise than a status page and it is one that can actually be kept at the current size, which is the trade this page is making everywhere.

• A major incident is communicated to the owner and administrators of every affected organisation
• Communication says what is affected, what is not, and what is being done — before it says what caused it
• An incident that turns out to be smaller than first reported is corrected in the same channel, not quietly dropped
• [[ Confirm the notification channel and the target time to first notice for a major incident, then replace this sentence — do not publish a time nobody has agreed to meet. ]]
• [[ Decide whether a written post-incident summary is offered to affected organisations, and within what period. ]]

This is the section most status pages would not include. The architecture specifies a recovery arrangement — regular full and incremental database backups with continuous write-ahead log archiving to object storage, replication of stored files, and a mandatory quarterly recovery drill. That arrangement is not yet implemented in the hosted deployment, and pretending otherwise would be the worst kind of claim to be wrong about.

• Continuous write-ahead log archiving is specified and is currently switched off in the deployment, because the tool that performs it is not yet part of the database image
• No recovery drill has been performed, and an untested backup is not a backup
• The message layer is deliberately not backed up: it carries transient work and the durable record lives in the database, so losing it costs a redelivery rather than data
• Client-side encryption keys cannot be backed up by Enclessa at all — the recovery phrase held by the user is the only backup that exists for them
• Closing this gap is operational work in progress and is the reason no availability figure is published

No availability figure is contractually committed on any plan, and Enclessa publishes none anywhere on this site. Internal engineering targets exist for latency and availability and are used to decide what to alert on; they are not customer commitments and are deliberately not reproduced here, because an internal target quoted on a marketing page becomes a service level agreement in every conversation that follows.

• No uptime percentage is published, because none is measured and published
• No service level agreement, no service credits and no availability guarantee on the standard plans
• No historical incident record exists, because none has been kept
• [[ Decide what, if anything, Enterprise commits to contractually — a named contact and an escalation path, or a figure — and state it here and in the terms identically. ]]