Status pages
A status page shows visitors the current and past state of the parts of your service you choose to publish, driven by the monitors you already run. It lives at https://statuspage.siteqwality.com/<account-id>/<page-id> or on your own domain.
Additional status pages and custom domains are paid status page extras. See plan limits.
When to use a status page
Section titled “When to use a status page”- Customers ask “where’s your status page?” before they buy.
- You want customers to answer “is it me or is it down?” themselves instead of opening a support ticket.
- You need one place to publish incident updates, so support doesn’t paste the same message into 40 conversations.
When not to use it
Section titled “When not to use it”- Don’t expose internal dashboards on it. Publish what is broken from a customer’s point of view: “DB read replica lag” means nothing to them.
- Don’t make it a marketing surface. The page exists to communicate facts during outages, and heavy custom CSS works against scannability.
How it works
Section titled “How it works”A status page has three layers:
- Status page object: the container, with branding (logo, colors, default theme) and an optional custom domain.
- Components: what the page reports on. Most link to a monitor (an HTTP check, a browser check or a heartbeat) and show its live status, with a public name and, for checks, an optional SLA target. A manual component has no monitor, and you set its status. Any component can carry a status override with a public note. When the page’s HTTP checks cover two or more websites, each shows its website’s icon.
- Incidents and maintenance: published events. You publish incidents and post their public updates yourself; internal notes never reach the page. A service can also publish the incidents it opens automatically, in the words of its public template, and those resolve when their monitors recover. Scheduled maintenance shows planned downtime ahead of time.
The page reads the same data as the dashboard, so a change in the dashboard shows up on it within about a minute. The same data is available from the public status page API.
What you can configure
Section titled “What you can configure”| Concern | Settings |
|---|---|
| Identity | name, page title, default theme (light, dark or system) |
| Branding | logo and dark theme logo, favicon, link preview image, primary and accent colors (kept readable in both themes), header and footer text, custom CSS, white-label (no Site Qwality badge or icon, and subscriber email carries your page’s name) |
| Custom domain | your own subdomain (e.g. status.example.com), with a TLS certificate provisioned for you |
| Components | HTTP, TCP port and ping checks, browser checks, heartbeats and manual components, with a public name, SLA target, status override, groups and order |
| Incidents | open, publish, update, resolve or unpublish by hand, or have a service publish the incidents it opens automatically |
| Maintenance | scheduled windows published ahead of planned work |
| Subscribers | visitors subscribe by email, confirm through a link, and choose incidents, maintenance or both, for every component or only some; you can import a list, and each address still confirms |
Subscriptions are email only. Anyone can also follow incidents by RSS or Atom.
Next steps
Section titled “Next steps” Quickstart Create, brand, and publish your first status page.
Add a custom domain Point status.yourcompany.com at your status page.
Manage subscribers Let visitors subscribe to incident updates.
API reference Status-page endpoints in the API.