Sign in
InOrbit
Docs
0%

Resources

Status

Whether InOrbit is up, for people and for programs. The status page, its answer and the API's health endpoints.

Everything on this page takes no token.

The status page

status.inorbit.hr shows how InOrbit stands right now: each part a customer uses (the website, the console, the API, sign-in, the docs, MCP for AI assistants and notifications), its state and its uptime over the last 24 hours, 7 and 30 days. Every state is measured by InOrbit's own monitors. The page names parts, never monitors, hosts or targets.

The same answer is one call:

curl https://api.inorbit.hr/v1/status
{
  "generated_at": "2026-10-09T21:03:19Z",
  "overall": "operational",
  "components": [
    {
      "name": "Website",
      "state": "operational",
      "checks": 4,
      "since": "2026-10-09T20:01:27Z",
      "uptime": { "h24": 0.9998, "d7": 0.9998, "d30": 0.9998 }
    }
  ]
}
  • overall is the worst component state: operational, partial_outage or full_outage.
  • A component's state is one of those three, or not_measured when no monitor measures it yet (checks is then 0 and uptime is absent).
  • uptime is the mean of the component's checks over each window, from 0 to 1.
  • since is when the state became what it is; empty when that is not known.
  • generated_at is when the answer was made. Treat it as stale after five minutes.

The API's health

GET https://api.inorbit.hr/healthz answers {"status": "ok"} while the gateway process is alive.

GET https://api.inorbit.hr/readyz answers the readiness report:

{ "ready": true, "services": { "engine": "serving", "accounts": "serving" } }

ready is true, and the status 200, while every backend the gateway requires is serving; otherwise 503 with the same body. A backend is serving, not_serving (it answered so) or unknown (unreachable or slower than the probe). A monitor polls /readyz; a client does not need to.

Changelog

What changed on the API and on these pages, by date.