The page

Reading the strips

The page shows one strip per monitor over the chosen range: the one the owner picked under Settings, Appearance (the last 24 hours unless they chose another), or 7 days, 90 days, or a year on Pro. Each bar is a bucket of checks and its height is the median response time, so a slowdown shows as a bump before anything fails while one slow check does not. Above it are the median over the range and the figure 95% of checks came in under. A heartbeat has no response time, so its bars are flat.

• Amber marks a timeout. Red marks any other failure.
• Consecutive failed checks are grouped into one entry under the strip, with the start time, the duration and the reason.
• A component has no checks, so its strip shows the state it was in: a short green bar for operational, indigo for degraded, red for down.
• Bars for the time before the page had history are shaded. Grey stubs are checks that ran during maintenance and were not counted.
• A dashed vertical line with a version label is a deploy marker, when the owner shows them.
• Times are shown in the zone the owner picked; the footer says which. The page reloads by itself as new checks land.

The headline

The headline says whether everything is up, and for how long. A monitor down makes it "part of X is down", every monitor down makes it "X is down", and a monitor slow with nothing down makes it "part of X is slow". An incident the owner opened with an impact outranks the checks while it is open, so the page can say something is wrong before a check notices. Open incidents are listed in the same order, worst first, with the ones somebody has written on before the ones a check opened; those are folded into one card while something else is open. A page with no monitors says it is not checked yet, in grey.

A state is shown with its age once its checks stop arriving: when a monitor's last check is older than three of its intervals (five minutes at the least; certificates and domains by their own rhythm), the monitor, the headline, the badge and status.json say "last checked 14 min ago" in grey. The service is not called down for it; the page says how old what it shows is.

Uptime target and error budget

A page can carry an uptime target, say 99.9%. The page then says, in its footer, how the month is going against it: the share of checks that passed, and the minutes of downtime spent out of the month's budget. The budget is what the target allows over the whole month (99.9% is 43 minutes in a 30-day month). Downtime is the share of failed checks applied to the time elapsed, so a monitor that failed 1 in 1,000 checks over 10 days has spent about 14 minutes. Slow time is shown the same way but does not spend budget. Maintenance windows and components never count.

On Pro, the first of each month brings an email report on the month before: uptime, downtime and slow time per monitor, the worst day, the incidents and how long each lasted, and the month against the target. It goes to the addresses the page's alerts go to and can be turned off under Settings, Alerts.

Logo, colours and time zone

Under Settings, Appearance: a logo shown above the headline, a favicon for the tab (the logo is used without one), an accent colour for the buttons and links, and whether the page follows the visitor's light or dark setting or is fixed to one. Buttons take the colour as given; links take a shade of it that reads on the page in each theme, and the screen says when the colour is close to one the page uses for a state. The same screen sets the range the page opens on and can fold a group of monitors to one line while everything in it is up. On Pro it can take "Powered by StatOSS" off the page; on a smaller plan the footer says it again. Images are up to 512 KB. A description and a support link under the headline live under Settings, General.

Times on the page and in the dashboard are shown in each visitor's own time zone, and the footer says which. The zone you pick here shows until the page has loaded, and to browsers that do not run scripts. Alerts and emails are in UTC. The same screen can ask search engines to leave the page out, which adds a noindex tag and keeps the page off our sitemap; anyone with the link can still open it.

On Hobby and Pro the screen also has the switch for the per-location lines and the check locations whose readings count toward response times; see Locations.

Password protection

On Pro, under Settings, Access, a page can take one shared password. Visitors are asked for it once and it is remembered on their browser for a month. status.json, the badge, the feeds, the MCP endpoint and llms.txt are locked too (the widget script loads but shows "Status unknown" without the key); the same screen shows a key that lets an embed through as ?key=. Changing or removing the password ends every earlier unlock and key. A locked page carries a noindex tag and stays off the sitemap. The API reads a locked page's status with a key of its own, whatever the password.

Private pages

On Pro, under Settings, Access, a page can be private: only the people on its list, anyone with an address at its email domains, and your team can see it. A visitor enters their address and gets a link by email that works once, for 15 minutes; it signs them in on that browser for 30 days. Someone added to the list gets an email with the page's address. Removing someone, or a domain, locks them out at their next visit; Sign everyone out does it for all at once and changes the page's key. Everything a password locks, a private page locks the same way, with the same kind of key. Subscribers subscribe with an address the page allows, while signed in, and a page that turns private stops sending to any other.