NuPaaS DocsStatus & health
Status answers "is my stuff working right now". SLOs answer "is my stuff working well enough over time". They are different questions and NuPaaS keeps them on separate surfaces.
Your status page
Every organization has a status view at /orgs/<org>/status. It shows your own services, addons and databases with a live status for each, rolled up into a single overall verdict and stamped with the time it was checked.
This page is available to every authenticated member of the organization, not just owners and admins. Health information is the one thing everyone on a team needs during an incident, so it is not gated behind an elevated role.
Status vocabulary
Component statuses are normalised from the underlying resource state into four values, so a database and a service can be compared on one page:
| Parameter | Type | Description |
|---|---|---|
| Operational | status | Running normally. |
| Degraded | status | Running below normal — reachable, but not healthy. |
| Outage | status | Errored, failed or crashed. Not serving. |
| Maintenance | status | Intentionally out of service. |
The overall banner is the worst case across components: any outage makes the organization's overall status an outage, and any degradation with no outage makes it degraded. It also reports how many components are operational out of the total, so a single degraded addon does not read the same as a broad failure.
Your workspace
An organization that has a workspace app turned on gets one more entry on its status page, beside its services, addons and databases: Workspace suite. It answers one question — did the platform's own probes for the suite answer — and it carries one row per probe the platform registers, so a probe added later appears without a change here.
The entry uses the vocabulary above, and each of its three probe states lands in one of those roles:
| Parameter | Type | Description |
|---|---|---|
| Operational | up | The pill reads "Up". The suite's own probe answered as expected. |
| Outage | down | The pill reads "Down". The suite's probe answered, and the answer was wrong. |
| Unknown | unobserved | The pill reads "Not reported". The platform has received nothing from this probe. |
The entry's own badge is the worst of its probe rows, and the line under it counts how many probes have reported out of how many are registered. A suite whose probes have reported nothing is an entry that says so, rather than an entry that counts to zero.
The entry appears only where there is a workspace to report on, and it carries no organization's data: the workspace suite is one shared instance serving every organization, so its state is the same wherever it is shown. An organization with no workspace app turned on sees no suite entry at all — not an empty card, and never a green one.
Organization readiness
Separately from component health, NuPaaS exposes a structured readiness check for the organization's own provisioning. It is what the panel polls while a new organization is being set up, and it reports each part independently rather than as one boolean:
| Parameter | Type | Description |
|---|---|---|
| tenantLinked | boolean | The organization is linked to its identity tenant. |
| authendReachable | boolean | The authentication service is answering. |
| memberCount | number | How many members the organization has. |
| billingActive | boolean | Billing is set up and active. |
| vclusterReady | boolean | The organization's isolated cluster is ready for workloads. |
| webhooksMissing | number | How many expected webhooks are not registered. Non-zero means some pushes will not trigger builds. |
| matrixSpaceLinked | boolean | The organization's collaboration space is linked. |
| isolationApplied | boolean | Tenant isolation policy has been applied. |
Service level objectives
An SLO is a target you set for one service in one project, evaluated on a rolling window. NuPaaS records the current value against the target, how much error budget is left, and how fast that budget is being spent.
SLOs are per-project. Alongside individual objectives, a project-level summary reports overall compliance, remaining error budget, and how many of its objectives are currently breached out of the total.
SLO fields
| Parameter | Type | Description |
|---|---|---|
| name | string | What the objective is called. |
| sliType | string | Which indicator is being measured. |
| target | number | The objective — the value the indicator should hold at or above. |
| windowDays | number | The rolling evaluation window, in days. |
| severity | string | How serious a breach of this objective is. |
| promqlQuery | string | An explicit query, when the default indicator is not what you want to measure. Optional. |
| refreshIntervalSec | number | How often the objective is re-evaluated. |
| lastEvaluatedAt | timestamp | When the objective was last computed. A stale value here means the number below it is stale too. |
Error budget and burn rate
The error budget is what the target permits you to spend: a 99.9% target over 30 days allows roughly 43 minutes of failure. Remaining budget is how much of that is left in the current window.
Burn rate is the more useful number day to day. It says how fast the budget is being consumed relative to the window — a burn rate above 1 means you will exhaust the budget before the window closes if nothing changes. A brief spike with plenty of budget left is usually not worth waking anyone; a sustained burn rate above 1 is, even while compliance still reads green.
What this page is not
Your status page reports the health of your organization's own resources. It is not a public status page for your end users, and it is not NuPaaS's own platform status — it will not tell you that the platform itself is having a bad day.
For the detail behind a status — which request failed, and why — go to Logs and telemetry. Status tells you something is wrong; telemetry tells you what.
platform logs <deploymentId> --tail 100