Platform
A status page you publish for your own users
Turn the monitors you already run into a public status page under your own name — component health, measured uptime and an incident timeline, derived automatically from real checks. Off by default, published when you say so.
This is the status page your organization publishes for its customers. It is a separate thing from Nivaronix's own status page, which reports on Nivaronix infrastructure. Nivaronix's own status page is over here.
What your users see
A published page answers the question your customers are actually asking — “is it me, or is it you?” — without anyone on your side having to update anything by hand: an overall status, a component list, measured uptime, an incident timeline, and your own branding on eligible plans. Every panel is built from monitoring data you are already collecting.
Where each status comes from
Component status is derived, not declared. There is no switch that says “show this as operational”. The rules are evaluated in this order, and the first one that matches wins:
Status | When it applies |
|---|---|
Maintenance | An active maintenance window covers the monitor's asset right now. Checked first, and it overrides everything below — scheduled work you already told your users about should not read as an outage. |
Unknown | The monitor is paused, disabled or not yet deployed; or there is no result yet; or the newest result is older than 15 minutes. A stale success is never allowed to read as "currently fine". If the check has gone quiet, the page says so. |
Down | There is an open incident on that monitor with critical severity. |
Degraded | The newest check did not succeed, or there is an open incident of any lower severity. |
Operational | The newest check is recent and succeeded, and no incident is open on that monitor. |
The page's overall status is the rollup: if any visible component is down, the page reads down; if any is degraded, it reads degraded. A page with nothing measurable on it reads unknown rather than pretending to be healthy.
Uptime that is measured, not asserted
Uptime is the proportion of recorded checks that succeeded, over 1, 7, 30 and 90 days. Every figure the page shows carries the number of checks it was computed from, because a percentage without its sample size is not a measurement.
If no checks ran in a window, the page says the window was not measured. It will never fill the gap with 100% — during exactly the failure where checks stopped, that would be precisely backwards. The same discipline governs how we report our own reliability.
What is published, and what never leaves
A published page is read by your customers, not your team. The public response is assembled from a narrow, fixed set of fields — internal detail is not hidden behind a permission check, it is simply never part of the response.
Published
The display names you chose for each visible component — not your monitors' internal names
Each visible component's current status and last-checked timestamp
Uptime percentages over 1, 7, 30 and 90 days, with the sample size behind each one
Incident title, ongoing-or-resolved state, start time and resolution time
Your resolved branding, and whether the page asks search engines not to index it
Never published
Incident descriptions, root-cause notes and postmortem working notes
Who owns or acknowledged an incident — no on-call names, ever
Your organization identifier, monitor identifiers or any other internal id
Components you have hidden, and any incident belonging to one
Anything about assets or monitors you never added to the page
Access works the same way: a published page is readable by anyone who has the URL, with no login. An unpublished page is not — and the URL of an unpublished page answers identically to a URL that was never created, so the address cannot be used to find out whether you have a status page at all.
What you control, and what the data decides
Property | Who decides it |
|---|---|
Whether the page is reachable at all | You. It is created unpublished, and stays that way until you publish it. |
The URL | You choose the slug: 3–63 characters, lowercase letters, digits and hyphens. It can be changed later. |
Which components appear | You. Add monitors you already run, rename them for a public audience, reorder them, and hide any of them without deleting them. |
Search engine indexing | You. The page asks search engines not to index it by default; turning that off is a deliberate choice. |
Branding | You, on plans that include white labelling. Saved branding applies as soon as the plan allows it, and reverts to default branding if the plan no longer does. |
Each component's status | Derived from that monitor's most recent check results, open incidents and active maintenance windows. There is no manual override. |
The overall status | Derived from the visible components: any component down makes the page down, any degraded makes it degraded. |
Uptime figures | Derived from recorded checks alone. A window with no checks reports as not measured rather than as 100%. |
The incident timeline | Derived from incidents already recorded against the components you are showing. |
Availability
Status pages are included on the Pro and Studio plans. Pro gets one page for the organization. Studio gets 26: one for each of its 25 clients, plus its own. The Free and Starter plans do not include them.
Custom branding is a separate entitlement from creating the page, and is checked every time the page is read — a plan change is reflected immediately rather than at the next save.
Any member of your organization can view the status page settings. Creating, publishing, rebranding and changing components require the settings-write permission.
Go deeper
Everything above is the whole story at a glance. Open this for the step-by-step detail behind it.