Public status pages
Every workspace includes a public status page, served at
status.alertkick.com/<your-subdomain> - the same subdomain you sign in
with. It is off by default. When you enable it, the page shows a banner
(“All systems operational”, “Some systems are experiencing issues”, “Major
outage”), a row per component, any incidents you have published, and a
14-day incident history.
The important property: component states are computed from your monitors, not typed in by whoever remembers the page exists. A monitor going critical flips its component to a major outage; recovery flips it back. During an incident the page keeps itself honest while you work.
Enable the page
Section titled “Enable the page”Monitoring, then Status Page lists your pages - every workspace starts with one default page. Open it, flip Status page enabled - the public URL appears next to the switch. Set a title (“Acme status”) and an optional description; both render at the top of the public page. The page is public the moment you enable it, so add your components first.
Multiple status pages
Section titled “Multiple status pages”One page is often not enough: a page per product, a page for a big customer, an internal-tooling page. Add Status Page creates an additional page (up to 10 per workspace). Additional pages are served at
status.alertkick.com/<your-subdomain>/<page-id>where the page id is a short random identifier AlertKick generates - it is
not guessable from your subdomain, so a page you share only with one
customer stays effectively unlisted until you publish the URL. Each page
has its own components, its own enable switch, and its own custom domain.
The default page keeps the bare /<your-subdomain> address. Additional
pages can be deleted from their settings; the default page can only be
disabled.
Components
Section titled “Components”Components are the rows on the page: “API”, “Dashboard”, “Background jobs”. Each has a name, an optional one-line description, and the things that prove it works:
- Linked monitors - any uptime, TCP, DNS, or other monitors. The component takes the worst state among them.
- Linked service - an infrastructure service. All of the service’s monitors count, and so do published incidents that affect the service.
Order the rows with the up and down arrows; the page renders them in the order you set.
How states are computed
Section titled “How states are computed”| Signal | Component state |
|---|---|
| A linked monitor is critical | Major outage |
| A linked monitor is warning | Degraded |
| Published incident on the linked service, severity P0 | Major outage |
| Published incident on the linked service, below P0 | Degraded |
| Monitor paused or disabled | Ignored |
Paused monitors contributing nothing is deliberate: pausing a check for planned work must not show your customers an outage. The banner takes the worst state across all components, and an open published incident keeps the banner off green even when every monitor has already recovered.
Publish an incident
Section titled “Publish an incident”Incidents are private until you say otherwise. On the incident detail page, flip Show on public status page, then give it a public title - the internal title stays internal, so “prod-db-eu-1 replica lag after failover” can go out as “Delayed dashboard data”.
Each update you post to the incident has its own public checkbox. Working notes stay private; the updates you mark public appear on the page under the incident, newest first. Resolved incidents stay in the Past incidents section for 14 days.
With more than one status page, a Show on these pages picker appears next to the switch: tick the pages this incident belongs on. Incidents published before you added extra pages stay on the default page.
Auto-publish
Section titled “Auto-publish”The settings page has an Auto-publish incidents section with a severity floor (P0 only, or P1 and above). It is marked coming soon: the setting is saved now and will take effect when incident automation ships. Until then, publishing is the manual switch above.
Custom domains
Section titled “Custom domains”The page can live on your own hostname, for example status.acme.com.
In Monitoring, then Status Page, add the hostname under Custom
domain, then create the CNAME record the page shows - it points your
hostname at AlertKick’s serving infrastructure. Ownership is validated
through the CNAME itself and the TLS certificate is issued and renewed
automatically: no TXT records to add, nothing to renew on your side.
The domain shows as pending until the record resolves, then flips to
active - Check status polls on demand, and validation normally
completes within a few minutes of the CNAME going live. A domain attaches
to one page at a time, and each page carries at most one domain - so a
workspace with a page per product can give each product its own status
hostname. Removing a domain frees it immediately. Your page stays
reachable at its status.alertkick.com address either way.
Serving details
Section titled “Serving details”The page is rendered by a separate read-only service and cached at the edge for 60 seconds, with a stale-if-error window - it stays up even if the origin has a bad day, which is the whole point of a status page. Changes you make appear within about a minute. The output is plain server-rendered HTML: no cookies, no JavaScript, respects dark mode, and loads fast on a phone.