> ## Documentation Index
> Fetch the complete documentation index at: https://docs.molesignal.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Status pages
> Publish incidents and maintenance, manage components and subscribers, protect private pages, verify custom domains, and automate updates.
Status pages turn operational state into controlled customer communication. Open **Status pages**
to create a page and manage it through seven focused workspaces.
## Workspace
| Tab | Purpose |
| --------------- | -------------------------------------------------------------------------------------------- |
| **Overview** | Review the summary, components, active incidents, and upcoming maintenance. |
| **Components** | Create, order, hide, restore, and update customer-facing service components. |
| **Incidents** | Draft, publish, update, monitor, and resolve unplanned events. |
| **Maintenance** | Schedule, publish, start, complete, or cancel planned work. |
| **History** | Search and filter terminal incidents and maintenance without expanding them on the overview. |
| **Subscribers** | Manage email and webhook subscribers, confirmations, and delivery results. |
| **Settings** | Configure general behavior, branding, localization, domains, access, and automation. |
## Create a status page
Select **Create status page**, then configure:
* a customer-facing name and globally unique slug;
* one or more interface languages, a default language, and an IANA timezone;
* **Public** or **Private** visibility;
* delivery retention, private session lifetime, and incident history window;
* logo, brand colors, and an optional custom domain.
English and Simplified Chinese localize the public interface. Component names, incident messages,
and maintenance updates remain exactly as your team writes them.
The default public address is /status/SLUG.
## Components
Each component has a name, description, order, visibility, and one of these customer-facing states:
* **Operational**
* **Degraded performance**
* **Partial outage**
* **Major outage**
* **Maintenance**
Hide a component when it should remain manageable but not public. Archive it when it leaves the
service catalog. Existing event history remains intact.
## Incident lifecycle
Create an incident as a draft, select affected components, set their impact, and write the first
customer update. Publishing makes the event public and sends the update to matching subscribers.
Confirm the symptom and communicate that the team is investigating.
Explain the known cause or the remediation currently underway.
State that service has recovered and the team is validating stability.
Publish the terminal update. MoleSignal restores the component state and adds one complete row
to **History**.
Every published update is immutable customer communication. Continue an incident by adding an
update rather than editing a previously delivered message.
## Maintenance lifecycle
Create planned work with a start and end time, affected components, impact, and customer message.
Publish it as **Scheduled**, move it to **In progress** when work starts, and finish it as
**Completed** or **Cancelled**. Terminal maintenance appears as one row in **History**.
## History
History contains only completed business events: resolved incidents and completed or cancelled
maintenance. Each row represents one event with its type, title, terminal status, affected
components, and date. Use search, type, status, component, and date filters with pagination. Select
a title to open the event timeline and updates without expanding the table.
The retention setting controls how far back the public incident archive reads, from 1 to 365 days.
It does not turn the overview into an unbounded event feed.
## Subscribers and delivery
Public visitors can select **Subscribe** and register an email address or webhook. Email
subscriptions use confirmation before activation. The management view separates pending, active,
and unsubscribed records.
Each published incident or maintenance update creates bounded delivery work for matching
subscribers. **Subscribers** shows attempts, success, the last error, and retry state. Delivery
retention can be set to 30, 60, 90, 180, or 365 days.
## Private access
A private page accepts email-address and email-domain allowlists. An allowed visitor requests a
single-use magic link, then receives a status-page session for 1, 7, or 30 days. Administrators can
revoke active sessions immediately. Private access applies to the public page, archive, event
detail, and subscription flow.
## Custom domain and TLS
Set http.external\_url to the real public MoleSignal URL before adding a domain. The
domain panel then shows the exact DNS ownership and routing records to create.
Domain state progresses through **Pending DNS**, **Verifying**, **Verified**, **Provisioning TLS**,
and **Active**. **Failed** or **Degraded** includes an actionable reason and a retry action.
To let MoleSignal serve the custom hostname with an automatically managed certificate, enable
http.tls and set the account email:
```toml theme={null}
[http]
external_url = "https://molesignal.example.com"
[http.tls]
enabled = true
account_email = "ops@example.com"
```
If TLS terminates at an external load balancer, keep the public URL and DNS target accurate and
manage the certificate at that edge.
## Publication automation
Open **Settings → Automation** to turn an operational event into a customer update.
1. Select **Alert incident** or **Synthetic monitor** as the source.
2. Choose the resource, minimum severity or monitor transition, and required labels.
3. Add a delay so a transient failure does not create customer communication.
4. Map the event impact and affected status-page components.
5. Choose **Manual approval** or **Automatic publishing** and define message templates.
6. Test the rule in the simulator before enabling it.
The first ordered rule that fully matches handles the event. A correlation key connects later
source transitions to the same incident. Manual mode creates a candidate that an authorized user
can approve, reject, or edit; automatic mode publishes the generated event directly. **Pause all
automation** stops new matches without changing events that are already public.
Use alert incidents for responder-owned detection and Synthetic monitors for direct customer-path
checks. Both sources can update the same component model, but each rule keeps its own approval and
delay policy.
## Permissions
| Permission | Capability |
| ---------------------------------- | ---------------------------------------------------------------------------------------- |
| status\_pages.read | Read pages, components, events, history, subscribers, domains, and automation state. |
| status\_pages.manage | Create and change pages, components, access, subscribers, domains, and automation rules. |
| status\_pages.publish | Publish customer updates and approve, reject, or apply automation candidates. |
| alerts.read | Select alert sources and use alert incidents in the automation simulator. |
Detect customer-path failures and drive status-page automation.
Configure the connectors and delivery operations used by incident responders.