Is this Nivaronix's status page?

No. This is a status page your organization publishes for your own users, on your own slug, showing your monitors. Nivaronix's own status page is a separate page reporting on Nivaronix infrastructure, and the slug "status" is reserved so the two can never collide.

Who can see my status page?

Anyone with the URL, once you publish it. There is no password or login on the published page. Before you publish, and after you unpublish, the URL behaves exactly as though no such page exists — an unpublished slug and a slug that was never created return the identical response, so nobody can use the URL to work out whether you have a page at all.

A Nivaronix-hosted path of the shape /status/your-slug. Custom domains are not supported today.

Will my status page show up in search results?

Not by default. A new page asks search engines not to index it, on the assumption that you will link it from your product rather than want it discovered. You can turn indexing on deliberately.

Can I mark a component as up when it is actually down?

No. Component status is derived from real check results, open incidents and maintenance windows, and there is no manual override. What you control is which components appear at all — you can hide one, but you cannot make a broken one read as healthy.

Will my customers see our internal incident notes?

No. The public incident feed carries only the incident title, whether it is ongoing or resolved, when it started and when it was resolved. Descriptions, root-cause analysis, owners and acknowledgements are never included in the public response.

What happens when uptime cannot be measured?

The window is reported as not measured rather than defaulting to 100%. Every uptime figure that is shown also carries the number of checks behind it.

How many status pages can I have?

One per organization, on the plans that include the feature. A single page can carry as many components as you have monitors to put on it.

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. Every panel on it is built from monitoring data you are already collecting.

An overall status: One rolled-up state for the page: operational, degraded, down, maintenance or unknown. It is computed from the visible components, not set by hand.
A component list: Each monitor you chose to show, under the display name you gave it, with its current status and when it was last checked. Order is yours to set.
Measured uptime: Uptime per component over 1, 7, 30 and 90 days — each figure carrying the number of checks it was computed from, so "99.9% over 40,000 checks" is never confused with "99.9% over four".
An incident timeline: Incidents on the components you are showing, as title, whether they are ongoing or resolved, when they started and when they were resolved. Nothing further.
Your branding, on eligible plans: Brand name, logo, primary and secondary colours and a link back to your site, applied to the page when your plan includes white labelling.

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.

Publishing one

Pick a slug
3–63 characters, lowercase letters, digits and hyphens, unique across Nivaronix. A short list of names is reserved and cannot be claimed — including status and nivaronix, so a customer page can never sit where Nivaronix's own status page lives.
Add components
Choose from the monitors your organization already runs. Each becomes a row with a public display name of your choosing — an HTTP check and an SSL check on the same asset can be two separate rows, or you can show just one.
Arrange and hide
Set the order, and hide anything you would rather not show. A hidden component stays fully manageable in your settings; it simply stops appearing publicly, along with its incidents.
Brand it
Set brand name, logo, colours and a link back to your site. Applied on plans that include white labelling.
Publish
Nothing is reachable until you publish. Unpublish at any time and the page goes back to being invisible.

Availability

Status pages are included on the Pro and Studio plans, with one status page per organization. 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.

Questions

Is this Nivaronix's status page?: No. This is a status page your organization publishes for your own users, on your own slug, showing your monitors. Nivaronix's own status page is a separate page reporting on Nivaronix infrastructure, and the slug "status" is reserved so the two can never collide.
Who can see my status page?: Anyone with the URL, once you publish it. There is no password or login on the published page. Before you publish, and after you unpublish, the URL behaves exactly as though no such page exists — an unpublished slug and a slug that was never created return the identical response, so nobody can use the URL to work out whether you have a page at all.
What is the URL?: A Nivaronix-hosted path of the shape /status/your-slug. Custom domains are not supported today.
Will my status page show up in search results?: Not by default. A new page asks search engines not to index it, on the assumption that you will link it from your product rather than want it discovered. You can turn indexing on deliberately.
Can I mark a component as up when it is actually down?: No. Component status is derived from real check results, open incidents and maintenance windows, and there is no manual override. What you control is which components appear at all — you can hide one, but you cannot make a broken one read as healthy.
Will my customers see our internal incident notes?: No. The public incident feed carries only the incident title, whether it is ongoing or resolved, when it started and when it was resolved. Descriptions, root-cause analysis, owners and acknowledgements are never included in the public response.
What happens when uptime cannot be measured?: The window is reported as not measured rather than defaulting to 100%. Every uptime figure that is shown also carries the number of checks behind it.
How many status pages can I have?: One per organization, on the plans that include the feature. A single page can carry as many components as you have monitors to put on it.

See which plans include status pages

Compare plans

Or read how the monitoring behind it works.