Trust centre
Service availability
What is monitored, what is alerted on, what recovery objectives are achievable with the current packaging — and, plainly, what has not been measured.
Right now
Current status
Placeholder — no live status feed is connected to this page — the indicator below is a placeholder and reflects no monitoring system. Replace with sourced, approved content before this page is made public.
No status feed connected
This page is not wired to a monitoring system. It will not tell you whether a service is up. For the status of your own deployment, use your monitoring stack; for a Baobyte-operated service, no such service is in operation.
History
Monthly availability
The shape of the record that will be published, with nothing in it.
Placeholder — no availability has been measured — every cell in this table is empty and must be populated from a monitoring system rather than by hand. Replace with sourced, approved content before this page is made public.
| Period | Availability | Planned maintenance | Unplanned downtime | Status |
|---|---|---|---|---|
| Month 12 (most recent) | — | — | — | Not measured |
| Month 11 | — | — | — | Not measured |
| Month 10 | — | — | — | Not measured |
| Month 9 | — | — | — | Not measured |
| Month 8 | — | — | — | Not measured |
| Month 7 | — | — | — | Not measured |
| Month 6 | — | — | — | Not measured |
| Month 5 | — | — | — | Not measured |
| Month 4 | — | — | — | Not measured |
| Month 3 | — | — | — | Not measured |
| Month 2 | — | — | — | Not measured |
| Month 1 | — | — | — | Not measured |
Incidents
Incident log
Every incident that reaches the two highest severities is intended to be published here with its timeline, impact, root cause and corrective actions.
Placeholder — no incident history exists to publish, and the publication criteria have not been agreed — an empty log is not evidence of a clean record. Replace with sourced, approved content before this page is made public.
No incidents published
This log is empty because no production service has been operated, not because a clean record has been established. An empty incident log on a new product is a statement about the product’s age, and it should not be read as a statement about its reliability.
The criteria for what gets published here, and how quickly, have not been agreed either.
Whose uptime
Availability is a property of the deployment, not of the software
Which is why this page spends more words on what is monitored than on what has been achieved.
The runtime is one Go binary in several run modes plus a Next.js web image. There is no service mesh, no message broker and no separate search or analytics engine — the stateful dependencies are PostgreSQL and the evidence store, and in the shapes that have been drilled both belong to the institution.
One constraint is worth knowing before capacity planning: the worker runs as exactly one instance and does not scale horizontally. Periodic jobs are declared per client, so a second replica duplicates every periodic job. Throughput is scaled through worker concurrency, not replica count. A dead worker is the failure mode to watch, because it produces no visible symptom until transaction partitions stop being created and inserts begin to fail — which is why the queue heartbeat alert is mandatory rather than advisory.
The API tier is stateless and can run one replica for a single institution or several for a multi-tenant deployment, in which case S3-compatible object storage becomes mandatory: pod-local evidence in a replicated deployment is refused at startup rather than silently mishandled.
Monitoring
What the platform exposes, and what must be alerted on
This part is not aspirational: these are requirements the deployment has to meet, and the metrics listener exists in the product today.
Exported today
- HTTP request volume, request duration and in-flight concurrency for the API.
- Database connection-pool occupancy, contention and churn.
- Worker readiness, queue depth, oldest available job age, retryable and discarded job counts, and last success time.
- Go runtime and process health.
- A dedicated metrics listener, separate from the API listener — the application refuses to start if the two are configured to the same address.
Route labels are normalised before export, and identifiers, raw URLs, job arguments and error text are never labels. That privacy property has to be preserved when configuring scraping — a relabelling rule that reintroduces them turns the metrics store into a second copy of customer data.
Alerts the deployment must implement
- Queue heartbeat failure — the periodic check that asks the database whether transaction partitions were created on schedule, whether rows landed in the default partition, and whether any jobs were discarded. This is the alert that prevents a silent partition-exhaustion outage.
- Worker not ready — the single worker instance is not processing. A dead worker produces no visible symptom until it becomes an outage with a date on it.
- Queue depth or oldest-job age growing — work is arriving faster than it clears.
- Discarded jobs above zero — retries have been exhausted on something.
- Backup job failure, and backup age — a backup that quietly stopped running is the most common way this data is lost.
- API readiness failure or database unreachable — direct service impact.
- Disk headroom on the database and evidence volumes — a full volume stops AML processing outright.
- TLS certificate expiry — sign-in breaks entirely at expiry.
- Audit chain verification failure — the integrity guarantee the product rests on.
Recovery
Recovery objectives, stated honestly
Recovery time and recovery point objectives are the institution's to define and approve per service. What follows is what the current packaging can and cannot deliver against them.
Recovery point. The shipped packaging runs a single PostgreSQL instance. There is no streaming replica, no write-ahead-log archiving or point-in-time recovery configured anywhere in the product’s packaging, and no automatic failover — recovery is a restore performed by a person. A daily backup gives a recovery point of up to twenty-four hours; twice daily, up to twelve. With nothing scheduled, there is no recovery point at all, and that is the default state of a fresh install.
If an institution requires a recovery point measured in minutes, no backup schedule reaches it. That requires continuous archiving or a replica — a checkbox and a cost line on a managed cloud PostgreSQL, and a real workstream on a self-managed VPS. It is the most consequential infrastructure decision in a Baobyte deployment.
Recovery time. A restore drill measured on a developer laptop — slower than any server an institution would recover onto — puts a hundred-gigabyte estate at roughly twenty-six minutes to restore, migrate and verify. That is a machine-executable floor, not a commitment. The recovery time an institution can actually commit to is that floor plus detection, decision, key retrieval from escrow, provisioning and validation, which normally dwarf it and which have not been measured for any specific deployment.
Placeholder — no maintenance window, no notice period for planned maintenance, and no service level objective have been agreed — these are contractual terms that belong in an SLA and none exists. Replace with sourced, approved content before this page is made public.
Planned maintenance and service levels
No maintenance window, notice period or availability target has been agreed. These are contractual terms and belong in a service level agreement negotiated with the institution; publishing an indicative figure here would create an expectation that nothing backs.
Operational readiness
Plan the recovery before the go-live
Backup schedule, key escrow rehearsal, restore drill on your own hardware, and the alert set that catches a stopped worker. These are the four that decide whether a deployment survives its first bad week.