Something wrong?
Write to a person
The parts
Where the service runs
One multi-tenant installation in a single European Union region, operated by a German company. Each organisation has its own subdomain or one verified domain.
How each part is watched
Live state not published during the open beta
- No public feed
Application and gateway
More than one replica; traffic only to instances passing readiness checks
- No public feed
Database
A standby copy takes over if the primary fails
- No public feed
Other core services
Some do not yet fail over automatically; a hardware failure can cause downtime
- No public feed
Message layer
Transient work only; the durable record lives in the database
- No public feed
Backups
Nightly, point-in-time for 30 days, restore test every quarter
How a failing instance is taken out of rotation
Liveness and readiness are checked separately. An instance that cannot reach its dependencies stops receiving traffic; one that stops responding is restarted.
- Migrations stay compatible across one version, so old and new processes share a schema during updates
- The application refuses to start against a schema that is too old
- Unsafe configuration is refused at start-up, not logged
Incidents
What counts as an incident
Defined by what a customer can observe. The level sets how quickly you are told, not how urgently it is worked on.
Majorsign-in fails, messages do not send, or the application does not load for a substantial share of organisations
Partialone capability is down or materially degraded: calls, uploads, search or notifications
Maintenancea planned change with visible effect, announced ahead of time
A personal-data breach follows the statutory timetable on the trust centre
How an incident is communicated
During beta, owners and administrators of affected organisations are contacted directly: what is affected, what is not, what is being done — then the cause.
- An incident that turns out smaller is corrected in the same channel
- No target time to first notice and no written post-incident report is committed during the open beta
Recovery
Backups and recovery
Nightly database backups with continuous log archiving allow restore to any point in the last 30 days. A quarterly test restores the newest backup in isolation and reads back every table.
30
days, any point in time
- Nightly backups, kept for thirty days
- Continuous log archiving for point-in-time recovery
- Quarterly restore test that alerts on failure
- The message layer carries transient work only and is not backed up
- Client-side encryption keys cannot be backed up by Enclessa; the user’s recovery phrase is the only backup
Plainly
What is not committed
No availability figure is committed on any plan or published on this site during the beta.
- No uptime percentage — none is measured and published
- No SLA, service credits or availability guarantee
- No incident history — none has been kept
- No recovery-time or recovery-point commitment
FAQ
Status questions
- No. There is no live status endpoint, uptime percentage or incident history yet. Until a real feed exists, this page documents the operational position and support@enclessa.app reaches a person.
- None. The service is in open beta; no availability figure is committed on any plan or published on this site.
- Yes: nightly backups with continuous log archiving, restorable to any point in the last thirty days, with a quarterly restore test. No recovery time is committed during the beta. A full export in open formats is the recovery route you control.