Status pages

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, group, 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, webhook, and Slack subscribers, imports, 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 the team writes them. The default language is also the language of the emails that the page sends. 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. A hidden component is left out of the public page and of subscriber notifications. Archive it when it leaves the service catalog. Existing event history remains intact. The public page lists each component with its status and a strip of the last 90 days. Under each strip, a scale reads 90 days ago, the uptime of the component, and Today. The description of a component appears in a tooltip behind the ⓘ beside its name.

Component groups

Group related components the way a folder holds files. Select Add component, set the type to Group, and give it a name and a description. Then choose the group under Group in the settings of each component that belongs in it.

A group has no status of its own. It shows the worst status among its components, and its strip shows each day as its worst component had it.
On the public page a group is one row with the number of its components. Readers unfold it to see each component. A group opens unfolded when one of its components is not operational.
A group holds components, not other groups. Incidents, maintenance, subscriptions, and automation rules name components; a group is never selected on its own.
Move up and Move down order a component among the components of its group, and a group among the top-level entries.
A group is archived once its components are moved out of it or archived.

Dependencies

A component can depend on technical services, synthetic checks, and alert rules. Its health is the worst status its dependencies pass on. MoleSignal works it out within seconds of a change of an alert incident or a synthetic check, and every minute in any case. Add dependencies in the settings of the component, under Dependencies:

Kind	Target	Status it passes on
Technical service	A service name, as traces and alerts carry it.	The worst open alert incident whose `service`, `service.name`, or `service_name` label names the service, or whose query saw it. The name is matched without regard to case.
Synthetic check	A synthetic check.	Major outage while the check fails, Degraded performance while it is degraded. A flaky check, a check that has not run, and a paused or archived check pass nothing on.
Alert rule	An alert rule.	The worst open alert incident of the rule.

An alert incident passes on its severity: critical is a major outage, error a partial outage, warning degraded performance. info changes nothing, and muted incidents are left out. Each dependency Passes its status on, or counts At most degraded when the component can work around it. A component has up to 100 dependencies; a group has none of its own. How the health reaches the component:

Mode	Behavior
Follow the health	The status of the component follows the health. Notify subscribers decides whether those changes are sent to subscribers. A status set by hand stays until the health changes again.
Through automation rules	Changes of health are a source of the automation rules of the page, which publish incidents with their delay, approval, and wording.

The settings of the component show the health last worked out and the dependencies that cause it.

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.

Investigating

Confirm the symptom and communicate that the team is investigating.

Identified or in progress

Explain the known cause or the remediation currently underway.

Monitoring

State that service has recovered and the team is validating stability.

Resolved

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.

Next update and notifications

Each update can promise the next one. Choose Next update when publishing: within 15 or 30 minutes, or within 1, 2, 4, or 24 hours, or No promise. The public page shows the promise on the incident and on the notice of an event that is under way, and emails and webhooks carry it. Updates that end an event, and maintenance that is only scheduled, promise nothing. Over the API, send next_update_at in microseconds, between 1 minute and 7 days ahead. Notify subscribers decides whether an update is sent to subscribers. Turn it off for a correction of wording: the page changes and nobody is written to. The timeline in the workspace marks such an update Subscribers not notified. The same switch appears when the status of a component is changed by hand. Over the API, send "notify": false.

Maintenance lifecycle

Create planned work with a public title, a start time, affected components, and a customer update. Maintenance has a planned start time and no planned end time, so state the expected duration in the customer update. Publish it as Scheduled and finish it as Completed or Cancelled. Terminal maintenance appears as one row in History. Scheduled maintenance acts on its planned start time by itself. Each maintenance carries two options, and both are on by default:

Option	API field	Default	Behavior
Automatic start	`auto_start`	`true`	At the planned start time, the maintenance moves to In progress and publishes an update in the default language of the page. Subscribers are notified as for any other update.
Reminder	`reminder_minutes`	`60`	That many minutes before the planned start time, subscribers receive a reminder. The reminder is not added to the timeline. `0` sends no reminder, and the longest lead time is 10080 minutes.

With automatic start off, move the maintenance to In progress when work starts. Maintenance that is announced or rescheduled after its reminder time sends no reminder, because subscribers have just been told. Rescheduling moves the reminder with the planned start time. An edit that names neither option leaves both as they are. MoleSignal checks planned start times about every 30 seconds.

Postmortems

A published incident can carry one postmortem, written in Markdown: what happened, why, and what changes because of it. Open the incident from Incidents or History and write it under Postmortem. Preview shows it as readers see it.

Action	Permission	Effect
Save draft	`status_pages.manage`	Keeps the text private. A draft can be written while the incident is still under way.
Publish postmortem	`status_pages.publish`	Available once the incident is resolved. The postmortem appears on the incident page below the updates, and the row of the incident in the public history says Postmortem. With Notify subscribers on, subscribers receive it.
Publish revision	`status_pages.publish`	Replaces the published text and records when it was revised. Notify subscribers is off by default for a revision.
Return to draft	`status_pages.publish`	Takes the postmortem off the public page.
Delete draft	`status_pages.manage`	Removes a postmortem that is not published.

A postmortem holds up to 20,000 characters. Emails and webhooks carry the Markdown text as written.

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, a webhook, or a Slack channel. Every channel is confirmed before it is activated. The management view separates pending, active, and unsubscribed records, and shows what each subscriber hears about. Under RSS feed the same dialog gives the page’s feed in two formats, to add to a feed reader with nothing to confirm: RSS 2.0 at /api/v1/public/status-pages/<slug>/feed.rss and Atom 1.0 at /api/v1/public/status-pages/<slug>/feed.atom. Both carry the latest 100 incidents and maintenance windows of the page, each with its most recent update. A private page has no feed. On a page with more than one component, a visitor chooses Whole page or Some components. A subscriber of some components receives only the updates that name one of them. Component groups appear as headings over their components. Every email ends with a link that manages the subscription and a link that ends it. The manage link opens the page with Manage subscription, where the components can be changed or the subscription ended. Registering an address that is already active sends a Manage your updates email instead of a new confirmation.

Slack

Way	How
Incoming webhook	Set the channel to Slack, paste an incoming webhook URL of the Slack channel (`https://hooks.slack.com/...`), and select Send confirmation. The confirmation is posted to the channel.
Add to Slack	Shown when the page names a Slack app in Settings → Slack. The visitor picks a channel in Slack and returns to the page. The channel is subscribed at once and receives a welcome message. A private page does not offer it.

A Slack message carries the subject as its header, the text of the update, and buttons that open the page and manage the subscription. To offer Add to Slack:

Create an app in Slack with the incoming-webhook scope. Under OAuth & Permissions → Redirect URLs, add the redirect URL that Settings → Slack of the page shows, <http.external_url>/api/v1/public/slack/callback. http.external_url must be an https address.
In Settings → Notify → Connectors, create a Slack app connector with the client ID and client secret of the app. The secret is kept encrypted with the connector. See Notification channels.
In Settings → Slack of the page, choose the connector and save.

Pages of an organization can share one connector. A connector that a page names cannot be deleted, and while it is turned off the page does not offer Add to Slack. Choosing Off stops offering it. Channels already added keep receiving updates either way.

Import subscribers

Bring email subscribers over from another status page with Subscribers → Import subscribers. Choose a CSV file or paste its content:

The first row can be a header with email and components columns in any order. Without a header, the first column is the address and the second names the components.
Components are named by name and separated by ;. The name of a group stands for the components in it. An empty cell subscribes the address to the whole page.
An import holds at most 10,000 addresses and 2 MB.

Start	Effect
Active at once	For addresses that confirmed on the old page. They are active immediately and are sent nothing.
Ask to confirm	Each address receives a confirmation email and stays pending until it confirms. Email delivery must be configured.

Check file reports what the import would do without changing anything: the rows read, the addresses to import, the addresses already subscribed, the addresses that unsubscribed before and are skipped, and each row with a problem by line number: no address, not an email address, an address named earlier in the file, or a component the page does not have. An email subscriber receives each update as a plain-text email in the default language of the page. Status names in the email match the labels of the page, such as Degraded performance.

Email	Subject	Body
Confirmation	`Confirm updates from <page name>`	The confirmation link and the unsubscribe link.
Component status change	`<page name>: <component> · <status>`	The component, its new status, and the page address.
Incident update	`<page name>: <title> · <status>`	The title, the status, the customer update, and the page address.
Maintenance update	`<page name>: <title> · <status>`	The content of an incident update, and Scheduled for with the planned start time.
Maintenance reminder	`<page name>: <title> · Reminder`	The title, Scheduled for with the planned start time, and the page address.
Manage	`Manage your updates from <page name>`	The link that manages the subscription.
Postmortem	`<page name>: Postmortem · <title>`	The postmortem in Markdown and the address of the incident.

An update that promises the next one adds Next update by and the time, in the timezone of the page. Every email but the confirmation ends with the manage and unsubscribe links. Scheduled for uses the timezone of the page and states the offset, for example 2026-05-25 12:00 UTC+02:00 (Europe/Berlin). A webhook subscriber receives each update as a JSON request. See Status page webhook subscriptions for the request format, the payload fields, and the retry schedule. 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. The email with the link is written in the default language of the page, and the link is valid for 15 minutes. 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:

[http]
external_url = "https://molesignal.example.com"

[http.tls]
enabled = true
account_email = "[email protected]"

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.

Select Alert incident, Synthetic check, or Component dependencies as the source.
Choose the resource, minimum severity or monitor transition, and required labels.
Add a delay so a transient failure does not create customer communication.
Map the event impact and affected status-page components. A Component dependencies rule that names no components publishes on the component whose dependencies changed, when that component hands them to automation rules. Its templates can name the component with {{labels.component_name}} and its statuses with {{labels.dependency_status}} and {{labels.previous_dependency_status}}.
Choose Manual approval or Automatic publishing and define message templates.
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.

Synthetic monitoring

Detect customer-path failures and drive status-page automation.

Notification delivery

Configure the connectors and delivery operations used by incident responders.

Get started

Data

Observe

Query and correlate

Reliability

AI ops

Collaboration

Admin

Deploy & operate

Best practices

Resources

Workspace

Create a status page

Components

Component groups

Dependencies

Incident lifecycle

Next update and notifications

Maintenance lifecycle

Postmortems

History

Subscribers and delivery

Slack

Import subscribers

Private access

Custom domain and TLS

Publication automation

Permissions

Synthetic monitoring

Notification delivery

​Workspace

​Create a status page

​Components

​Component groups

​Dependencies

​Incident lifecycle

​Next update and notifications

​Maintenance lifecycle

​Postmortems

​History

​Subscribers and delivery

​Slack

​Import subscribers

​Private access

​Custom domain and TLS

​Publication automation

​Permissions

Synthetic monitoring

Notification delivery

Workspace

Create a status page

Components

Component groups

Dependencies

Incident lifecycle

Next update and notifications

Maintenance lifecycle

Postmortems

History

Subscribers and delivery

Slack

Import subscribers

Private access

Custom domain and TLS

Publication automation

Permissions