Publishing public updates

Keep your customers in the loop without leaving the incident.

Plan availability

Status pages is available on Pro and Business. See the plan comparison.

Overview

During an incident, you'll often want to tell your customers what's going on — not the technical detail your team needs, but a calm, plain-language update they can understand. Getting ahead of it like this is what turns a wobble into "they clearly have it handled". Public updates do exactly that: you write one from inside the incident, tie it to a friendly status, and it appears on your status page for anyone with the link to read.

Public updates sit alongside your internal notes on the same timeline, so you keep the full picture in one place while choosing what your customers see. For the team-only side, see Incident updates and timeline.

What you need

Publishing a public update needs more than the Incidents feature on its own. It requires both:

• The Incidents feature, so you have the incident timeline to publish from, and
• A status page for the update to appear on.

In practice that means a Pro or Business plan. You also need to be an owner or admin — the same permission that lets you create and manage status pages. Members can read the incident and post internal notes, but they won't see the publish option.

If you've got the Incidents feature but no status page yet, the composer still works for internal notes, and it'll point you towards comparing plans so you can add a status page.

How to publish an update

You publish from the incident detail page, using the same Post an update box you'd use for an internal note:

1. Open the incident.
2. In the update box, switch the audience from Team only to Public.
3. Pick the status that best describes where things stand (see below).
4. Write your message in plain language — there's a live preview showing exactly how it'll read on your status page.
5. Click Publish update.

DomainDash confirms with "Published to your status page.", and the update appears on the public page straight away.

There's a starter sentence for each status

When you choose a status, DomainDash offers a friendly opening line in its own tone — for example, "We're looking into a problem affecting this service and will share an update shortly." It's only a starting point; edit it to fit before you publish. Public updates are kept short on purpose so the status page stays glanceable.

The status levels

Every public update is tied to one of four status levels. These are the only words your customers see — the labels are deliberately friendly and non-technical:

Status	What it tells customers
Looking into it	You're aware of a problem and investigating
Found the issue	You know what's causing it and you're working on a fix
Almost fixed	A fix is in place and you're keeping a close eye on it
Fixed	Everything's back to normal

DomainDash suggests a sensible default that follows the incident's live state — "Looking into it" while it's ongoing, "Fixed" once it has resolved — but you can always choose a different one.

Publishing after an incident resolves

You can still publish a "Fixed" update after an incident has resolved. Like internal notes added after resolution, it's recorded as part of the incident's lasting write-up while still appearing on your status page — so your customers get a reassuring all-clear and your team keeps the post-mortem, both from the one update.

Related

• Incident updates and timeline for internal, team-only notes
• What visitors see for how public updates appear on your status page
• Creating a status page to set up the status page these updates publish to
• How incidents work for the incident lifecycle behind the updates