Managing Incidents - Statux Pages Help

Report service disruptions, keep your users informed with regular updates, and manage your incident history from creation to resolution.

Creating an Incident

When a service disruption occurs, creating an incident is the fastest way to communicate the issue to your users. Incidents appear on your public status page and trigger notifications to subscribers.

To create a new incident:

Navigate to Active Incidents in the sidebar.
Click Create Incident.
Fill in the following fields:
- Title: A clear, concise description of the issue (for example, “Elevated API Error Rates” or “Database Connectivity Issues”). This is the first thing your users see.
- Status Page: Select which status page this incident should appear on.
- Affected Components: Select one or more components that are impacted by this incident. Their status on the public page updates accordingly.
- Severity: Choose the impact level — Minor, Major, or Critical (see below).
- Initial Message: Write the first status update. Be honest, concise, and factual about what you know so far.
Click Create Incident to publish.

Severity Levels

The severity level communicates the scope and impact of the incident to your users:

Minor: A small subset of users or a non-critical feature is affected. Core functionality remains available. Example: a minor UI glitch or a non-essential background job failing.
Major: A significant portion of users or an important feature is affected. Core functionality may be degraded. Example: slow response times across the platform or intermittent failures on key endpoints.
Critical: The service is completely unavailable or a critical function is broken for all or most users. Example: total API downtime, data loss risk, or a security breach.

Tip: When in doubt, start with a higher severity. It is better to over-communicate than to under-communicate during an outage. You can always downgrade the severity as you learn more about the issue.

Applying Templates

If you have pre-configured incident templates, you can use them to speed up incident creation. When creating a new incident:

Click the Apply Template button at the top of the creation form.
Select a template from the dropdown.
The template pre-fills the title, severity, initial message, affected status pages, and affected components.
You can still edit any field before submitting the incident.

Note: Templates are especially valuable during high-pressure situations. Having pre-written messages for common scenarios (database outage, payment processing failure, etc.) means your team can respond in seconds instead of spending critical minutes drafting a message.

Incident Lifecycle

Every incident in Statux Pages follows a four-stage lifecycle. As you progress through resolution, you update the incident status to keep your users informed about where things stand.

1. Investigating

The initial status when an incident is created. Your team is aware of the issue and actively looking into it. At this stage, you may not yet know the root cause.

Best practice: Post an initial message acknowledging the issue and letting users know you are looking into it. Even a short message like “We are aware of the issue and investigating” is better than silence.

2. Identified

The root cause has been determined. You understand what is causing the issue and are working on a fix.

Best practice: Share what you have learned about the cause (at a level appropriate for your audience) and provide an estimated time to resolution if possible.

3. Monitoring

A fix has been implemented or deployed, and your team is watching for recurrence or confirming that the fix is effective.

Best practice: Let users know the fix is in place and that you are monitoring. Provide guidance on what users should do if they continue to experience issues.

4. Resolved

The incident is fully resolved. Services are operating normally again.

Best practice: Post a final update summarizing what happened, what was done to fix it, and any follow-up actions planned (such as a post-mortem or preventive measures).

Note: You do not have to go through every stage sequentially. For example, if you identify and fix the issue quickly, you can skip from Investigating directly to Resolved. However, going through each stage provides the most transparency to your users.

Posting Updates

Regular updates during an active incident are critical for maintaining user trust. Each update is timestamped and appears on the public status page in chronological order.

To post an update:

Click on the active incident from the Active Incidents list.
In the incident detail view, write your update message in the update form.
Optionally change the incident status (for example, from Investigating to Identified).
Optionally update the severity level if the scope has changed.
Click Post Update.

Subscriber Notifications

Every time you post an update to an incident, subscribers who are subscribed to the affected status page receive an email notification. The notification includes:

The incident title and severity.
The new status (Investigating, Identified, Monitoring, or Resolved).
The update message you wrote.
A link to view the full incident on your status page.

Best practice: Post updates at regular intervals, even if there is no new information. A message saying “We are still investigating and will provide another update in 30 minutes” is far better than silence. Aim for updates every 15 to 30 minutes during active incidents.

Linking Related Incidents

When multiple incidents are caused by the same underlying issue, or when one incident leads to another, you can link them together for better traceability.

To link related incidents:

Open an incident from the Active Incidents or Archived list.
In the incident detail view, look for the Related Incidents section.
Click Link Incident and search for or select the related incident.
The link is bidirectional — both incidents will show the relationship.

Linking related incidents helps your team:

Identify patterns and recurring issues across your infrastructure.
Understand cascading failures (for example, a database outage causing API errors).
Conduct more thorough post-incident reviews.

Searching and Filtering Incidents

As your incident history grows, searching and filtering help you quickly find specific incidents.

Search

Use the search bar at the top of the incidents list to search by incident title or content. Results update as you type.

Filters

You can filter the incidents list by:

Status: Investigating, Identified, Monitoring, or Resolved.
Severity: Minor, Major, or Critical.
Search text: Free-text search across incident titles and update messages.

Filters can be combined. For example, you can view all Critical incidents that are currently in the Investigating status.

Active vs. Archived Incidents

The incidents section has two tabs:

Active: Shows all incidents that are currently open (Investigating, Identified, or Monitoring) as well as recently resolved incidents that have not been archived yet.
Archived: Shows incidents that have been moved to the archive. Archived incidents are still fully viewable and searchable but are separated from the active list to reduce clutter.

Archiving an Incident

Resolved incidents can be archived manually or are automatically archived after a configurable period. To archive an incident manually:

Open the resolved incident.
Click Archive.
The incident moves to the Archived tab.

Restoring an Archived Incident

If you need to reopen or reference an archived incident:

Switch to the Archived tab.
Find the incident and click Restore.
The incident moves back to the Active tab.

Note: Archiving an incident does not affect subscriber notifications, uptime calculations, or the incident's visibility on your public status page's history. It only moves the incident to the Archived tab in the dashboard for organizational purposes.