What a status page shows#
A status page is a curated, customer-facing view of selected services. Only the services an administrator lists appear, under the public names they choose, and an incident appears only once a responder publishes a status update from it. The internal incident title and number never appear on the page.
The Web application serves each page at /status/SLUG without a login. A page is public, or private with a secret link (?key=…) that is shown once when you save it and can be rotated. To use a separate hostname such as status.example.com, point it at the Web application and rewrite / to /status/SLUG in your reverse proxy.
Create a status page#
- Open Status Pages under Configure as an organization administrator and create a page with a name and URL slug.
- Tick the services to list and give each the name the public should see, for example Checkout rather than an internal service name.
- Choose public or private. For a private page, copy the secret link when it is shown.
- Share the URL and check it from the network your audience uses.
Publish an update during an incident#
Open the incident, expand Status page update, pick a state (Investigating, Identified, Monitoring or Resolved) and write a sentence for customers. Optionally set a public title of up to 120 characters; it names the incident on the page and in subscriber emails, and later updates keep it unless you change it. Without one, the service's public name is used.
- The update appears on every status page that lists the incident's service.
- The service shows as Major outage for P1 and P2 incidents, and Degraded performance for lower severities.
- The incident timeline records the update, and every subscriber of those pages is emailed.
- If an incident with published updates is resolved without a final update, the worker publishes "This incident has been resolved." Resolved incidents stay on the page for 14 days.
- Maintenance windows that cover a listed service appear under Scheduled maintenance and show the service as under maintenance while they run.
Publishing needs the responder, team admin or organization admin role, the same as acknowledging.
Email subscribers#
Each page has an email subscribe form. A subscriber receives one email per published update with the page link and a one-click unsubscribe link. Subscribing twice to the same page changes nothing, and the API accepts at most 200 new subscriptions per page per hour. Emails are plain text and deliberately minimal.
What status pages need#
| Requirement | Why |
|---|---|
| PUBLIC_BASE_URL set to the Web application's public origin | Builds the page URL shown to administrators and in emails. |
| PUBLIC_API_URL set to the API's public origin | Builds the unsubscribe link in emails. |
| The Web application reachable by your audience | The page is served by the Web application; the visitor's browser never talks to the API. |
| An email provider | Organization SMTP or the deployment SMTP settings. Without one, updates still appear on the page and subscriber deliveries are retried, then marked failed. |
Stakeholders#
Responders get paged; stakeholders get told. A stakeholder follows a service or a team and receives an informational email, and a push for app users, when incidents open, are acknowledged, get an update or resolve. Stakeholders are never part of an escalation policy: organization viewers and plain email addresses outside AckNexa both work.
- Edit a team or service and open Stakeholders. Team admins manage the lists for their own teams.
- Add a person in AckNexa or type an email address, and pick the moments they hear about: opened, acknowledged, updates posted, resolved.
- For app users, choose whether to push as well.
A stakeholder who is an AckNexa user can open the incidents they follow in the Web application and the apps, read-only unless their team role allows acting. Deliveries are retried up to six times, and the Stakeholders panel shows how many went out in the last 30 days per person.
Post a stakeholder update#
In the incident drawer, tick Send to stakeholders before posting a note. The note becomes an update on the timeline and is emailed to everyone following the service or its team with updates enabled. Ordinary notes stay internal. Outbound webhooks carry the same update event, so another system can mirror it.