Operations

Operations

How to check that the service is up, what we operate for you on managed cloud, what happens during a restart, and how to reach support.

01 — Health check

GET /healthz on the API host returns HTTP 200 with a JSON body whose status field is ok. Use it for uptime checks. From 1.4.2.2 the body’s version field is the release (for example 1.4.2.5) and build_id names the build; earlier releases read 0.1.0.

$ curl -s https://<api-host>/healthz { "status": "ok", "service": "invariantdb", ... }

02 — Managed cloud

On managed cloud, we run the servers: deploys, restarts and monitoring. Contact support about backups for your graphs. You create graphs and API keys in the dashboard.

For the current availability posture, see Availability.

03 — Deploys and restarts

Deploys restart the server. Writes are refused while it restarts; acknowledged writes are recovered from the write-ahead log on startup. A large graph can take longer to open after a restart. If a request fails during a restart, retry after a short wait; when the response includes a Retry-After header, wait that long.

04 — Backup and restore

Backups are compressed archives of a graph that restore as a new graph. The archive’s files are checked against their integrity hashes when the restored graph opens. See Backup and restore.

05 — Self-hosted servers

The operator guide for self-hosted servers, covering installation, configuration, monitoring, and upgrades, ships with your production contract. Contact support to request it.

06 — Support

What to include in a support request

  • Graph name
  • Time window (UTC)
  • The x-request-id response header, if you have it
  • The error, code, and subcode fields from the error response

Support email

support@invariantdb.com

Response targets

Response targets are set in your production agreement.

Plan a production deployment

Contact us to discuss availability targets, support terms, and self-hosting.