Choose which incidents affect a component
Each service mapping has a minimum incident severity and a debounce interval. A brief or lower-severity internal incident need not immediately change the customer-facing state.
Keep customers informed while your team responds.
Publish service status, incident updates, and planned maintenance on public or private status pages. Give customers a clear account of what's affected and what happens next.
Describe your service in your customers’ terms.
Name the components customers recognize, then connect them to the internal services that affect them. A customer-facing “Payments” component can represent several internal systems without exposing their incident details.
Read the product guideMake the source relationship explicit
Heartbeats contribute through their owning service’s mapping. Organizing monitors into a group does not itself publish that group as a status component.
Group the customer view
Arrange related components into named groups so visitors can scan the service at a useful level. A group reflects its most affected component; each component retains its own status.
Keep internal evidence inside the response
Internal incident titles, alert payloads, and responder timelines are not automatically published as customer messages. Your team writes the explanation customers should receive.
Give the right audience a clear place to look.
Publish a public page or use a private page for an invited audience. Page, component, and subscriber allowances follow your plan; Business and Enterprise add private pages when private hosting is enabled.
Read the product guideInvite readers without adding responder seats
Private pages admit eligible workspace members and invited viewers. External viewers can read the page without becoming billable responders. A viewing invitation and an email subscription are separate choices.
Keep private pages private as access changes
Removing a viewer stops access renewal immediately; access already issued to a browser expires within five minutes. Losing a private-page plan allowance does not make the page public.
Connect a private page to your own hostname
Business and Enterprise support custom private hostnames when custom-domain hosting is enabled. Verify DNS ownership, add the displayed routing record, and let WarnFire manage HTTPS. The hostname retains private sign-in checks.
Choose what subscriber email contains
Private update emails link readers to sign in by default. Owners and administrators can include customer-facing details instead. Delivered email remains with its recipient after viewing access is removed.
Write the update you want customers to receive.
Create customer incident messages, post follow-ups, correct text, and schedule publication in the web console. Give customers an account of the affected components and the progress of the response.
Read the product guideWrite once for the customer audience
Choose a customer-facing title, incident state, affected components, and update text. Keep credentials, internal links, and responder-only details in the internal record. Review the customer preview before publishing.
Check the publication result
Publishing is queued. A saved message or console preview does not prove the hosted page has changed; check the publication state and the served URL. Withdrawal is also asynchronous.
Correct text without rewriting the sequence
Editing an update preserves its recorded state and post time. Corrections do not resend email that has already been delivered, and deleting an update cannot recall an email someone received.
Let readers choose their updates
Email subscriptions require confirmation and are specific to each page. New customer updates and component changes notify subscribers after publication. Every message includes an unsubscribe link for that page.
Keep operational control with the response team.
Use the web console for components, mappings, customer messages, subscriptions, and publishing. In the mobile app, responders can inspect pages and pause or resume eligible monitoring.
Read the product guidePause planned work with an end time
Choose a maintenance window and an internal reason, with a separate optional customer message. Pausing affects monitors in the component’s enabled linked services, including services shared with other components.
Resume without erasing the incident
Existing incidents and earlier outages remain recorded during maintenance. Resume early or let the window expire. Monitoring returns with a fresh deadline; overlapping maintenance stays in effect until all applicable windows end.
Change the display when that is the intent
A manual status override changes what customers see and can have an expiry. It does not pause monitoring. Keep its internal reason separate from the optional customer message.
Show history with visible coverage
Publish 30- or 90-day availability history from recorded component status. Unknown periods remain unknown, and both unknown time and planned maintenance are excluded from the uptime denominator.
Choose the control that matches the work.
These controls serve different purposes. Check shared services before pausing a component, and verify the hosted page after publishing.
| Intent | Control | Effect |
|---|---|---|
| Reboot a monitored service | Pause monitoring | Creates a bounded maintenance window for linked monitoring; existing incidents remain |
| Correct the customer-facing state | Manual status override | Changes the displayed component status while monitoring continues |
| Explain planned work or an incident | Customer update | Publishes the message your team writes; authoring a message does not itself pause monitoring |
Build a response people can follow.
Start a workspace, connect a service, and make the next signal reach its owner.