Manage incidents
Declare an incident, work it from the incident page, publish updates to your status pages, and resolve or delete it when you are done.
An incident is your team's internal record of something going wrong: who is leading, who is responding, what has been tried, and what customers have been told. This page walks through the full life of one, from declaring it to resolving it.
Declare an incident
Go to Incident Management → Incidents and click Declare incident. You can also declare from Slack, see Respond from Slack. The form asks for:
Title: a short internal name for the incident, for example "Checkout API returning 500 errors". It shows in the incidents list, the timeline, and Slack messages.
Summary: optional free text for what you know so far. You can edit it later from the incident page.
Incident Status: where the response stands, one of Investigating, Identified, Monitoring, or Resolved. Most incidents start at Investigating.
Affected Service: the incident management service that is impaired. Picking a service pre-fills the severity and decides whether the incident can be published.
Service Status: how badly that service is affected, Degraded, Partial outage, or Unavailable. This immediately becomes the service's live status on the Services page.
Severity / business impact: optional. Minor, Major, or Critical, pre-filled from the service's default. Severity drives which runbooks match and the impact published to status pages.
Commander: the person leading the response. Defaults to you.
Responders: everyone helping. At least one is required, and you are added by default.
If the service is mapped to a status page, a Publish to Status Page card appears at the bottom. Switch it on to publish an incident notice at the same time as you declare. The card previews exactly what will happen, for example "2 public services on Acme will be updated to Partial outage", and asks for a Public Title (pre-filled from your title), a Public Message, and whether to Notify Subscribers. Only what is inside that card reaches the status page. The card is hidden for services with no mapping.
Click Declare Incident. Any runbook whose rules match the service and severity fires straight away, which is how a Slack channel gets created and how manual steps land on the incident page. You are returned to the incidents list, where the Ongoing and All tabs show each incident with its severity, status, and the affected service's current state.
The incident page
Click an incident in the list to open it. Everything about the response lives here.
Title and Summary: click either one to edit it in place. Changes save when you click away.
Manual runbook steps: if a matching runbook has script steps, each one appears as a card with the script to run. Click the check mark when it is done and the step is recorded in the timeline.
Post update form: type an internal update and click Post Update. Turn on Publish to Status Page to also post it to the status page, covered in the next section.
Timeline: newest first. Internal updates carry an Internal badge. Published updates carry a Status Page badge and expand to show the public title, the public message, the page it went to, and the impact set on each component. Between them, single-line entries record who declared the incident, status and severity changes, service status changes, Slack channels created, and runbook steps completed. The menu on an update lets you edit its internal text or delete it. Public text cannot be edited, and deleting an update that was published also removes its public counterpart from the status page.
Properties, in the right sidebar: the incident status and severity. Change either and click Save changes.
Affected Service: the service and its current status. Moving the status here updates the service's live status and logs the change in the timeline.
Commander and Responders: reassign the lead, or use the menu next to Responders to search for and add or remove people.
Menu in the top right: Resolve and, for admins, Delete.
Publish updates to status pages
Publishing is available whenever the affected service is mapped to status page components, or the incident already has a notice. Write your internal update, switch on Publish to Status Page, and fill in the public part:
Public Title appears only the first time you publish, because it names the notice. Later updates are appended to that notice.
Public Message is what subscribers and visitors read. Keep it separate from the internal text, which stays private.
Notify Subscribers sends the update through the page's notification channels. Leave it off for minor updates you want visible but not pushed.
Click Post Update. On every status page the service is mapped to, StatusPal Next posts the message as a notice update with the incident's current status, and sets the mapped components' impact to match the incident's severity: Minor shows as Degraded, Major as Partial outage, Critical as Unavailable. Without a severity, the service status is used instead. The timeline card records exactly what went out and where.
Resolve and delete incidents
To resolve, open the menu in the top right and choose Resolve, or set the incident status to Resolved in the sidebar. Resolving sets the affected service back to Operational and, if the incident was published, posts a Resolved update on every linked notice and returns the mapped components to Operational. The resolution text comes from your resolution notice template if you have one, otherwise it reads "This incident has been resolved."
Resolved incidents stay in the All tab with their full timeline. Reopen one by changing its status back in the sidebar.
Only admins can delete an incident, from the same menu. Deletion is permanent and removes every internal update. Notices already published to your status pages are kept, so the history on those pages stays intact.
Last updated