kharazm

Operations

Service status

We do not run a third-party status page, because doing so would mean embedding someone else's script and telling you we run no trackers. This page is the honest version instead: what to check, what we commit to, and what is not built yet.

Checking availability right now

The application exposes two endpoints. /healthz reports process liveness. /readyz additionally verifies database connectivity and fails closed — it returns an error rather than a false positive when the database is unreachable. The hosting platform uses readiness for its own service check, so a failing database takes the instance out of rotation rather than serving broken pages.

If the application is reachable and /readyz is healthy, the service is up.

Reporting a problem

Email hello@bakaroart.com. It reaches the people who build and operate the service directly — there is no support tier and no ticket queue in front of them.

For a suspected security issue, email the same address rather than opening a public issue. See the security page.

What we commit to

During an incident

  1. We tell affected customers directly

    By email, to the workspace administrators. We would rather write to you than expect you to discover a status page.

  2. We say what happened, not what sounds better

    Including when the cause was our mistake. A compliance customer needs an accurate account far more than a reassuring one, because they may have to explain the gap themselves.

  3. We state whether data was affected

    Explicitly, in the first message, including "we do not yet know" when that is the truthful answer.

  4. Published records are never silently altered

    A published report cannot be edited by anyone, including us. If a recovery ever required restoring to an earlier point, affected customers would be told which records were involved and when.

Stated plainly

What is not built yet

An operations page that lists only strengths is marketing. These are tracked gaps.

No automated uptime history

There is no public historical availability chart, and we will not publish a number we cannot substantiate. Ask us about a specific period and we will tell you what we know.

No formal SLA

Availability commitments and credits are not part of the published terms. A written arrangement is possible for an organization that needs one — write to us.

Backup drills are not yet routine

Point-in-time recovery depends on the database plan in use, and operator-owned off-box restore drills are on the roadmap rather than in the past. Stated the same way on the security page.

Planned maintenance

Disruptive maintenance is scheduled outside United States business hours where it is within our control. Administrators are emailed in advance when a change is expected to interrupt access.

The service runs one always-on instance, so ordinary deployments do not require a maintenance window.