Managing Incidents

Middleware Status Page incidents communicate outages, degraded performance, and other service disruptions. Each incident links the affected services with a public timeline of investigation and recovery updates.

When you create or update an incident, Middleware updates the affected service status, adds an entry to the public incident timeline, and notifies configured email subscribers.

A typical incident progresses from investigation to resolution:

Investigating → Identified → Update → Monitoring → Resolved

View Incidents#

You can create and manage incidents from:

• Status Page → Incidents: View incidents associated with a specific status page.

Use the Status Page view when managing incidents for a specific page, or the global incident list when you need to review incidents across your project.

Create an Incident#

From a status page, Click on any status page -> open the Incidents tab and select Create Incident.

Add Incident Details#

Enter information describing the incident.

Title :Enter a short description of the issue.

For example: Elevated API latency in us-east-1

Use a title that clearly identifies the affected functionality or service.

Select Affected Services#

Select one or more services affected by the incident.

Only services already added to the Status Page are available for selection.

Middleware updates the status of the selected services based on the configured Impact Type.

Set the Incident status#

It defines how the incident affects the selected services.

For example, use Degraded when a service remains available but is experiencing increased latency, and Downtime when the service is unavailable.

Set the Workflow Status#

Workflow Status represents the current stage of the incident response.

Impact Type describes service health; Workflow Status describes response progress. For example, a service can remain degraded while the response moves from investigation to monitoring.

• Impact Type controls the health status of the affected services.
• Workflow Status communicates the current stage of the incident response.

Each saved update is added to the incident timeline on the public Status Page.

Save the Incident#

After configuring the incident, select Save.

Middleware then:

1. Updates the status of the affected services based on the Impact Type.
2. Creates the incident and its first timeline entry.
3. Recalculates the overall Status Page state.
4. Sends an email notification to configured subscribers.

The incident is now visible on the public Status Page.

Update an Incident#

As the incident progresses, open it from the Incidents tab

Update the incident as needed:

1. Change the Workflow Status to represent the current response stage.
2. Change the incident status if the impact on services has changed.
3. Update the Message with the latest information.
4. Select Save.

Each saved update creates a new timeline entry and sends another notification to configured subscribers.

The public Status Page keeps the incident history with timestamps so visitors can follow its progress.

Resolve an Incident#

When the affected services have recovered:

1. Open the incident.
2. Set Incident Status to Resolved.
3. Set Workflow Status to Resolved.
4. Add a final message describing the resolution.
5. Save the incident.

Setting the Impact Type to Resolved returns the affected service status to Operational.

The final update is added to the public timeline and sent to subscribers.

How Incidents Affect Status Page Health#

Incident Impact Type affects the status of selected services, which in turn affects the overall Status Page banner.

Middleware uses the most severe state among the services on the page.

For example, if five services are operational and one is degraded, the page displays Some Systems Degraded.

Incident Timeline#

Every time an incident is created or updated, Middleware adds an entry to its public timeline.

The public timeline preserves the sequence of incident updates so visitors can follow what happened and how the response progressed.

Each update includes its timestamp and the information provided for that stage of the incident.

Use the timeline to provide ongoing updates instead of creating a new incident for each change in the same issue.

Subscriber Notifications#

When an incident is created or updated, configured email subscribers receive a notification.

The notification includes:

• Incident title
• Current workflow status
• Affected services
• Incident message
• Link to the Status Page

Configure subscribers before creating an incident if you want users to receive updates throughout the incident lifecycle.

Delete an Incident#

You can delete an incident when it should no longer appear on the Status Page.

Deleting an incident removes:

• The incident from the public timeline.
• Its timeline history.
• Its associated service bindings.

Deleting an incident does not restore the affected services to Operational.

If an incident affected service status, resolve the incident by setting its Impact Type to Resolved before deleting it.

Incident Response Workflow#

A typical incident lifecycle can follow this flow:

Issue detected ↓ Investigating + Degraded/Downtime ↓ Identified ↓ Update ↓ Monitoring ↓ Resolved + Resolved Impact

1. Investigating#

Create the incident when an issue is detected.

Set the Impact Type to Degraded or Downtime, depending on the effect on the service.

2. Identified#

Change the Workflow Status to Identified when the cause of the issue has been found.

Add a message explaining the current findings when appropriate.

3. Update#

Use Update to communicate progress while work on the incident continues.

4. Monitoring#

After applying a fix, set the Workflow Status to Monitoring while verifying that the service remains stable.

5. Resolved#

Once the service has recovered, set both:

Workflow Status = Resolved Impact Type = Resolved

This closes the incident and returns the affected service status to Operational.

Best Practices#

• Use specific incident titles: Describe the affected service or behavior instead of using generic titles such as "Issue detected."
• Post updates during an active incident: Keep the public timeline current as the investigation progresses.
• Select only affected services: Avoid changing the status of services that are operating normally.
• Use Impact Type and Workflow Status correctly: Impact represents service health; Workflow Status represents incident progress.
• Resolve incidents explicitly: Set both the Impact Type and Workflow Status to Resolved when the issue is fixed.
• Configure subscribers in advance: Add subscribers before an incident occurs if they need to receive email updates.