12.3What visitors see

The page shows, from top to bottom:

Your title and description.
An overall status line, with as of <time> UTC.
Open incidents, only when an incident is open.
Services: one row per monitor, with its public name, its state and 90 days of uptime.
Maintenance, only when you have planned maintenance (12.4).
Resolved in the last 14 days: resolved incidents, or No incidents.
A footer that says Refreshes every minute.

All times on the page are in UTC. If no monitors are on the page, Services reads No services are listed on this page yet.

Overall status#

Status line	When it shows
All systems operational	Every service is up.
Degraded performance	No service is down, but some are degraded.
Partial outage	Some services are down, but not all.
Major outage	Every service is down.
Under maintenance	No service is down, degraded or without recent data, and some are in a maintenance window now.
Some services have no recent data	No service is down or degraded. Some are up, and some have no recent data.
No recent data	No service is down, degraded or up. Some have no recent data.
No status to report yet	There is nothing to show yet.

Paused monitors, monitors under maintenance, and monitors with no data do not count toward Partial outage or Major outage.

Each service's state#

Each service shows one state. If more than one fits, the first one in this table wins.

State	What it means
Not monitored	You paused the monitor.
Under maintenance	A maintenance window covers it right now.
Down	It has an open incident, or its last check failed.
No recent data	obsrvly has not checked it recently. This is a problem on obsrvly's side, not with your service.
Degraded	Its last check passed, but too slowly or only in part.
Operational	Its last check passed.
No data yet	It has not been checked yet.

A certificate check that passes but is close to expiry shows as Operational. It counts as up.

90-day uptime and daily history#

Uptime is how much of the time a service was up. Each service has a strip of 90 bars, one per day in UTC. The oldest day is on the left. Today is on the right, marked today.

Bar	Meaning
no downtime	100% up that day.
some downtime	At least 98% but under 100% up.
under 98% up	Below 98% up.
no data	A short bar. Nothing was measured that day. It never counts as 100%.

Under the strip, the page shows the total, such as 90 days: 99.95% uptime, or 90 days: no data.
Point at a bar to see that day, such as Mon, 6 Oct 2026: 99.95% uptime. With a keyboard, select the strip and use the arrow keys, Home and End.
Percentages show two decimals and are rounded down. A day with any downtime never shows 100%.
Uptime is the same as in the dashboard. Checks during a maintenance window do not count.

Incidents#

An incident is a period when a monitor is failing. Incidents on the page are the same incidents you are alerted about. They follow your alert policy (chapter 9). A single failed check, or a single missed heartbeat, does not always create one.

Incident	What visitors see
Open	`Ongoing`, or `Ongoing, being worked on` after someone acknowledges it (9.6). Also `Since <time> UTC (<duration>)`.
Resolved	`Resolved after <duration>` and `<start> UTC to <end> UTC`.

Durations read like 25 min, 3 h or 3 h 10 min under 48 hours, and 4 days after that.
Open incidents and incidents resolved in the last 14 days are shown. An incident that started more than 90 days ago is not shown.
Visitors never see the error message or who acknowledged the incident. Certificate expiry warnings are not shown.
You cannot write incident updates on the page. Incidents come only from your monitors.

Updates and errors#

After you save, the page shows the change within about a minute.
If you turn the page off, it disappears within about a minute.
A wrong address, a page that is off, and a suspended team all show There is no status page here.
If the page shows This status page could not be loaded, the problem is on obsrvly's side, not with your services. Visitors can select try again after a minute.

Build your own view (API)#

Developers can read the public data and show it in their own way. These three calls need no API key and no Authorization header. Each takes the page's address as slug.

Read a public status page

PUB=https://www.obsrvly.com/api/gw

curl -s $PUB/monitor/obsrvly.v1.MonitorConfigService/GetPublicStatusPage \
  -H "Content-Type: application/json" \
  -d '{"slug": "acme"}'

curl -s $PUB/result/obsrvly.v1.ResultService/GetPublicStatus \
  -H "Content-Type: application/json" \
  -d '{"slug": "acme"}'

curl -s $PUB/alert/obsrvly.v1.AlertService/ListPublicIncidents \
  -H "Content-Type: application/json" \
  -d '{"slug": "acme"}'

Call	What it returns
`GetPublicStatusPage`	`title`, `description`, `monitors` in page order (`key`, `name`, `paused`), and `maintenance` (windows not yet ended: `title`, `startsAt`, `endsAt`, `monitorKeys`).
`GetPublicStatus`	For each `key`: `status` of the last check (`CHECK_STATUS_UP`, `CHECK_STATUS_DOWN` or `CHECK_STATUS_DEGRADED`), `uptimePct` over 90 days, `days` (90 items of `date` and `uptimePct`, in UTC), and `noRecentData`.
`ListPublicIncidents`	`incidents`, each with `monitorKey`, `startedAt`, `resolvedAt` and `acknowledged`.

key stands in for the monitor's ID. It is the same in all three answers. It stays the same while the monitor stays on the page. If you remove a monitor and add it back, it gets a new key.
uptimePct is -1 when nothing was measured. A value of 0 is left out of the answer, so treat a missing uptimePct as 0.
status is left out when the monitor has no check in the last 90 days, and when noRecentData is true. Show noRecentData: true as No recent data, never as up.
An empty monitorKeys means the window covers every monitor on the page.
You can make up to 60 requests a minute from each IP address. Past that, you get resource_exhausted (429).
A wrong address, a page that is off, or a suspended team answers not_found (404) with status page not found.
GetPublicStatus and ListPublicIncidents also answer not_found when no monitors are on the page, and for a moment after a first save.