Status Pages

This page covers the full lifecycle of a status page: create it, add services, publish, post and resolve incidents, and manage who gets emailed.

For what a status page is and how service health is derived, see On-Call Overview → Status pages.

Create a status page

Create a page and give it a title (e.g. Acme US) and an optional description. Each page gets its own public web address of the form your-page.status-pages.<your-domain>.

New pages start Private, so you can set everything up before anyone sees it.

Add your services

Add the components you want to show, for example API, Dashboard, and Webhooks. For each service you can set:

• Name and an optional description.
• Visible: whether it appears on the public page.

Every service starts Operational. You won't set the live status by hand, since it's driven by your incidents (see below).

Publish the page

When the page is ready, switch its visibility to Public. It's now live at its web address. Switch back to Private at any time to take it down.

Post an incident

An incident is for something actively affecting your services. When you create one you provide:

• A title (e.g. Elevated API error rates).
• A status: Investigating, Identified, Monitoring, or Resolved.
• An opening message (markdown).
• The affected services and, for each, the impact (Degraded performance, Partial outage, Major outage, Under maintenance).

As soon as you post it, the affected services show the impact you chose, and the incident appears under Active incidents.

Add timeline updates

Add timeline updates to an incident as you learn more. Each update carries a new status and a message, and they stack into a chronological thread your users can follow. Moving the status to Monitoring, then Resolved, walks the incident through its lifecycle.

Resolve it

Set the status to Resolved. Autoheal stamps the resolved time, recalculates the affected services (they return to Operational once no open incident affects them), and moves the incident from Active incidents into Recent updates.

Backfilling history? If you create an incident that's already resolved (to record something that happened earlier), subscribers are not emailed, because only live activity notifies people.

Post an update

Use an update post for anything that isn't a lifecycle incident, such as a general announcement or a scheduled-maintenance notice. An update is a single, editable message with no status and no service impact. Edit it in place as plans change. Update posts always appear under Recent updates. At this point, this is what end users see.

Section	Contains
Active incidents	Incidents that aren't resolved yet, with their latest updates
Recent updates	Resolved incidents + update posts from the last 15 days, newest first

Older history remains available through the page's history view.

Use your own domain (optional)

By default your page is served at your-page.status-pages.<your-domain>. You can also serve it on your own subdomain, for example status.yourcompany.com.

In the page's Settings → Custom domain (CNAME):

1. Enter your subdomain and click Add.
2. At your DNS provider, add the CNAME shown under "Point this CNAME to" so your domain points at Autoheal.
3. Contact Autoheal support (support@autoheal.ai or on Slack). We issue the TLS certificate for your domain, send you an ownership-validation record to add at your DNS provider, and route your domain. Once that's done, your page is live on it.

Your default …status-pages.… address keeps working throughout the setup, and continues to work alongside your custom domain afterward.

What you can use:

• A subdomain you control, like status.yourcompany.com, and not your root/apex domain (yourcompany.com), because a root domain can't be pointed with a CNAME.
• One custom domain per status page, and it must not already be in use by another page.
• Standard hostname characters (letters, digits, hyphens). It must be your own domain, not an Autoheal …status-pages.… address.

Subscriptions

Visitors to a public status page can subscribe by email to be notified when you publish or update posts. Autoheal uses double opt-in so people only ever receive mail they explicitly asked for.

How a visitor subscribes

1. On the public page, the visitor enters their email address and submits.
2. Autoheal sends a confirmation email ("Confirm your subscription to <your page> status page") from notifications@autoheal.ai, shown as "<Your Page> Status Page (Autoheal)".
3. The visitor clicks Confirm subscription. Only after this step are they subscribed. The confirmation link is valid for 72 hours; after that they subscribe again to get a fresh link.

Until they confirm, no further email is sent. Re-submitting the same address within the confirmation window won't spam them, since it re-sends the same pending confirmation rather than a new one.

What subscribers receive

Once confirmed, a subscriber is emailed whenever you:

• Publish a new incident,
• Post an update to an incident (including when you resolve it), or
• Publish an update post.

Each notification includes the post title, the latest message, any affected services, and a link to the status page. Every message also includes a one-click Unsubscribe, both as a link in the email body and via the native "Unsubscribe" button mail apps show (RFC 8058), so it works everywhere.

Subscribers receive all of a page's updates; there is no per-service subscription at this time.

Unsubscribing

A subscriber can unsubscribe at any time using the link in any email or their mail app's built-in Unsubscribe button. Unsubscribing is immediate and they'll receive nothing further. If they later change their mind, they can subscribe again, which re-runs the confirmation step.

Adding subscribers as an admin

You can add a subscriber's email from the page's Subscribers view. They still receive the same confirmation email and must confirm before they get updates, because Autoheal never adds an unconfirmed address to your live send list.

Delivery & privacy notes

• Confirmed only. Notifications go only to addresses that completed double opt-in and haven't unsubscribed.
• Bounce/complaint protection. Addresses that hard-bounce, are flagged as spam complaints, or land on a suppression list are dropped from future sends to keep your sender reputation healthy.
• Subscriber email addresses are treated as personal data and are not exposed on the public page.