Sign in
Trust

Reliability

Draft: under legal review
These pages are not a certificate, an SLA or a signed DPA.

What we do not promise

We do not publish an uptime percentage, an availability target, a status page, or a zero-downtime commitment. This page describes what we actually run instead.

The production database

Stella’s data lives in one managed PostgreSQL 18 database hosted by Render in Oregon, with no high availability and no read replicas. The hosting plan has no managed point-in-time recovery, so the logical dump is the backup.

What counts as a backup

  • A full, encrypted-in-transit dump of the database, with a record of its row counts, checksum and size taken at dump time.
  • A dump counts as a backup only after it has been restored into a fresh database and its row counts match that record. An unverified dump is not treated as a backup.
  • We keep at least the two most recent verified backups.
  • We re-run the full restore drill before any destructive operation, and monthly otherwise.

The search index is rebuilt, not restored

The search index (Pinecone) is not dump-restorable. After a restore we rebuild it by re-reading your restored documents. Each backup records what the index should contain, so we can check the rebuild is complete.

How often we test it

A scheduled job runs the backup and the restore check on the first of each month, and on demand. When either step fails, the job fails and opens a tracking issue. The job needs a machine that can reach the database; until that machine is in place, scheduled runs wait for one rather than report success they have not earned.

Our first verified restore drill was on Jun 12, 2026. Before that date the database had never been backed up; since then a verified restore path exists.

If production has to be rebuilt

We provision a fresh database in the same region, restore the latest verified backup, check its row counts, point the service at it, confirm it is ready, and rebuild the search index from your restored documents. That is how we recover the service — it is not a failover commitment, and it is not a zero-downtime plan.

Incidents

Incident response is one of our security measures, and we tell you of a personal data breach within 72 hours of becoming aware of it. We do not publish a broader incident-response SLA.

Reliability · Trust · Stella