Resources

Status page

Where to check whether VMYard is up, what each state means, recent check history, and the machine-readable status JSON.

VMYard publishes service status in two places. Neither needs a sign-in.

Page	Where	Keeps history	Up when the console is down
Console status	/status on the console	No, current state only	No
Independent status page	Its own address, such as `status.<your domain>`; the console footer's Status link opens it when your deployment runs one	Yes, the recent checks it has made	Yes

If the console doesn't load, open the independent status page. Your VMYard operator gives you its address, and the console's footer and Support page link to it.

States

State	Meaning
Operational	The component answered normally.
Degraded	It answers, but isn't ready for every request; some requests may be slow or fail.
Outage	It answers with server errors, or doesn't answer at all.
Unknown	It couldn't be checked: the first check hasn't finished, the check is misconfigured, or the status host itself has no network access.

The overall state is the worst component's state. An active incident raises it: a minor-impact incident to at least Degraded, a major-impact one to Outage.

What the independent page checks

It runs on a separate host from the console and the API, and checks each public health endpoint from outside, by default every 30 seconds. It sends no credentials and shows only component names and fixed descriptions, never addresses or error messages.

For each component it shows the result of each of the most recent checks it has made, newest on the right, with a count such as "Operational in 118 of the last 120 checks", and a Recent changes list of state changes with times. It keeps only the checks it has observed itself (120 by default), so history starts when the page was first deployed and has no gaps filled in later.

Current incidents, scheduled maintenance, and incidents from the last 7 days appear on both pages when your deployment publishes them.

Status JSON

The independent page serves the same data at status.json next to the page, for scripts and monitors. It allows cross-origin reads.

json

{
  "observed": true,
  "overall": "degraded",
  "checked_at": "2026-10-12T12:00:00.000Z",
  "components": [
    {
      "name": "API",
      "state": "degraded",
      "summary": "Answering, but not ready for every request"
    },
    {
      "name": "Console",
      "state": "operational",
      "summary": "Answering normally"
    }
  ],
  "incidents": { "active": [], "upcoming": [], "recent": [] },
  "history": [
    {
      "at": "2026-10-12T12:00:00.000Z",
      "overall": "degraded",
      "components": { "API": "degraded", "Console": "operational" }
    }
  ]
}

Field	Notes
`observed`	`false` until the first check after the page starts; `checked_at` is then `null` and every component is `unknown`.
`overall`, `components[].state`	`operational`, `degraded`, `outage`, or `unknown`.
`incidents`	`null` when the deployment publishes no incidents, `"unavailable"` when they couldn't be read, otherwise `active`, `upcoming`, and `recent` lists.
`history`	The kept checks, oldest first.

Getting help

Open Support in the console sidebar, or /support, for your deployment's support contacts and copyable diagnostic info. The independent status page also lists the support contacts in its footer.