# Status pages

Build and publish public status pages from selected monitoring data.

import ProductScreenshot from "@/components/docs/ProductScreenshot.astro";
import blockEditorScreenshot from "@/assets/screenshots/guides/status-pages/block-editor.webp";
import builderScreenshot from "@/assets/screenshots/guides/status-pages/builder.webp";
import statusPageListScreenshot from "@/assets/screenshots/guides/status-pages/list.webp";
import publicDataScreenshot from "@/assets/screenshots/guides/status-pages/public-data.webp";
import publicPageScreenshot from "@/assets/screenshots/guides/status-pages/public-page.webp";

Status pages publish selected monitoring health without requiring a Netstamp account. Each page belongs to a project and is available at `/status/<slug>`.

<ProductScreenshot
	src={publicPageScreenshot}
	alt="Public Netstamp status page with overall health, incidents, and service history"
	caption="Visitors see only the service blocks and incident history selected for this public page."
/>

## Create a status page

<ProductScreenshot
	src={statusPageListScreenshot}
	alt="Status-page registry with visibility, slug, state, and actions"
	caption="The registry separates page administration from the unauthenticated public view."
/>

1. Open **Status pages** in the project.
2. Choose **New page**.
3. Set a name and unique slug.
4. Add the checks that should be public.
5. Configure the page presentation and save it.

Open the public URL in a private browser window to verify what an unauthenticated visitor can see.

<ProductScreenshot
	src={builderScreenshot}
	alt="Status-page builder with settings and a live service preview"
	caption="Build the page while reviewing its public presentation in the adjacent live preview."
/>

## Choose what to publish

Use status pages for externally meaningful services rather than every internal check. Group checks around the service language your audience understands, and use clear display names.

Before publishing, review check names, probe names, locations, labels, targets, and incident text for internal topology or customer information. Do not put secrets in any of these fields.

<ProductScreenshot
	src={publicDataScreenshot}
	alt="Status-page public-data controls for targets, probe names, locations, incidents, and generated time"
	caption="Treat every enabled field as an explicit disclosure decision before publishing."
/>

## Interpret status

The page derives health from the selected monitoring data. A public page is only as representative as its checks and assigned probes, so confirm that:

- Checks cover the actual user path.
- Probes run from relevant networks or regions.
- Disabled or stale checks are not presented as current evidence.
- Alert and incident behavior matches the public message you intend to communicate.

<ProductScreenshot
	src={blockEditorScreenshot}
	alt="Status-page block editor for assignment scope, display mode, chart range, and public label"
	caption="Each block chooses its monitored source and the information shape visitors will see."
/>

## Change a slug or remove a page

Changing the slug changes the public URL. Update bookmarks, DNS redirects, and external references after a change.

Disable or delete a page when it should no longer be public. Then verify the old URL from an unauthenticated session and remove any reverse-proxy or CDN caching that could retain it.

Treat a status page as a public interface: keep its scope deliberate, review it after monitoring changes, and test it during incident exercises.

Before sharing the URL, review the underlying [checks](/docs/guides/checks/) and [alert behavior](/docs/guides/alerts-and-incidents/).