Incident Creation

Incidents communicate service disruptions to your clients in real time. Declaring an incident — rather than quietly fixing a problem — builds trust and reduces support ticket volume. Clients who see a status update stop calling to ask what's wrong.

Declaring an Incident

1. Open the status page and click the Incidents tab
2. Click Create Incident
3. Fill in the incident form:

Field	Required	Description
Title	Yes	Short, clear description of the problem — e.g., "Help Desk Ticket Submission Disrupted"
Status	Yes	Starting status — usually "Investigating"
Impact	Yes	Severity level (see table below)
Affected Components	No	Select which components are impacted; their status updates automatically
Initial Message	No	First update text visible to clients immediately

4. Click Create

The incident appears on the public status page immediately, and subscribers receive a notification.

💡Use plain language in incident titles and messages. Your clients are business owners, not engineers. "Email Delivery Delays" is clearer than "SMTP relay queue backlog on MX cluster 2".

Impact Levels

Impact	When to Use
None	Investigating a potential issue with no confirmed client impact
Minor	Small subset of users affected or minimal service degradation
Major	Most users experiencing disruption; service usability significantly reduced
Critical	Complete outage; service unavailable to all or nearly all users

Selecting an impact level automatically updates the affected components to an appropriate status (e.g., Critical → Major Outage; Minor → Degraded).

Incident Status Workflow

Incidents move through a defined lifecycle. Each status change creates a new entry in the incident timeline visible on the public page.

Investigating → Identified → Monitoring → Resolved → Postmortem

Status	Meaning
Investigating	Team is aware and looking into the cause
Identified	Root cause has been found; fix is in progress
Monitoring	Fix has been applied; team is watching to confirm resolution
Resolved	Service is confirmed restored
Postmortem	A post-incident report has been published (set automatically when postmortem is published)

Posting Incident Updates

Post regular updates to keep clients informed, even when there is nothing new to report. A "We're still investigating" update every 30 minutes is better than silence.

1. Click the incident (from the Incidents tab or public page)
2. Click Post Update
3. Enter the new Status (e.g., change from "Investigating" to "Identified")
4. Write an Update Message describing what you know
5. Click Post

Each update is timestamped and appended to the incident timeline. Subscribers receive a notification for every update.

Example Update Sequence

Time	Status	Message
2:05 PM	Investigating	We are aware of reports that help desk ticket submission is failing and are investigating.
2:22 PM	Identified	We have identified a database connectivity issue affecting ticket creation. A fix is being applied.
2:45 PM	Monitoring	The database issue has been resolved. We are monitoring to confirm service is fully restored.
3:00 PM	Resolved	Help desk ticket submission is fully operational. We apologize for the disruption.

Resolving an Incident

When the service is confirmed restored:

1. Post a final update with status Resolved
2. Write a resolution message clients can read
3. Click Post

Resolved incidents move out of the "active incidents" section and into the incident history. Affected components return to their pre-incident status (or Operational if no other issues are active).

Retroactive Incidents

You can create an incident after the fact to document a disruption that has already been resolved. Set the initial status to "Resolved" and include a description of what happened and when. This maintains a complete incident history even for brief outages that were resolved before you had time to create an incident in real time.

Deleting an Incident

On the incident detail, click Delete. This permanently removes the incident and all its updates from both the management view and the public page history.

⚠️Do not delete incidents to hide outages. This undermines client trust. Instead, use resolved incidents as a record of your response quality.

Postmortems

For significant incidents, publish a postmortem to explain what happened and what you're doing to prevent recurrence.

Creating a Postmortem

1. Open the resolved incident
2. Click Add Postmortem
3. Fill in the fields:

Field	Description
Title	E.g., "Post-Incident Report: Help Desk Outage — March 5, 2026"
Summary	One-paragraph executive summary of the incident
Impact Description	How many clients/services were affected and for how long
Root Cause	Technical explanation of what caused the incident
Corrective Actions	What you're doing to prevent recurrence
Timeline	Detailed timeline of events (optional structured entries)

4. Save as Draft while writing; click Publish when ready to make it public

Published Postmortems

Published postmortems appear on the public status page linked from the resolved incident in the incident history. They are visible to all visitors, including clients who were not subscribed. Subscribers who received the incident notifications are not automatically re-notified when a postmortem is published.

💡Publishing postmortems is a strong trust signal. Clients see that you take accountability, investigate thoroughly, and act to prevent repeats. Many MSPs see reduced churn after consistently publishing postmortems.