Managing Incidents

Incidents let you communicate outages, degradations, and maintenance to your customers. When you create or update an incident, Middleware updates affected service statuses, records a timeline entry, and sends email notifications to subscribers.

Where to manage incidents#

You can create and manage incidents from two places:

• Status Page → Incidents tab — incidents scoped to a specific status page
• Synthetics → Incidents — global incident list across all pages

Create an incident#

Update an existing incident#

Open an incident from the Incidents tab or global list to post follow-up updates:

1. Change the workflow status to reflect progress (e.g. from Investigating to Identified)
2. Update the impact type if the situation changes (e.g. from Degraded to Resolved)
3. Edit the message with new information
4. Save — a new timeline entry is created and subscribers are notified again

The public status page shows the full incident history with timestamps, so visitors can follow the progression of your response.

How incidents affect page status#

The page-level banner reflects the worst state among all added services:

• If any service is in downtime, the banner shows Some Systems Experiencing Downtime
• If any service is degraded (and none are in downtime), the banner shows Some Systems Degraded
• If all services are operational, the banner shows All Systems Operational

Delete an incident#

Deleting an incident removes it from the public timeline along with all associated history entries and service bindings. This does not revert service statuses — update or create a new incident with Resolved impact if you need to restore operational status.

Notification content#

When an incident is created or updated, email subscribers receive a notification containing:

• Affected service names
• Link to the status page
• Current workflow status
• Your message (or the default message)
• Incident title

Ensure you have subscribers configured before reporting your first incident.

Incident response workflow#

A typical incident lifecycle:

1. Investigating + Degraded or Downtime — initial report when you detect an issue
2. Identified — root cause found, share what you know
3. Update — periodic progress updates for subscribers
4. Monitoring — fix deployed, watching for stability
5. Resolved + Resolved impact type — confirm the issue is fixed and services are healthy

Best practices#

• Post updates regularly — even brief "still investigating" messages reduce support ticket volume
• Be specific in titles — "Payment processing delays" is more useful than "Issue detected"
• Resolve explicitly — set impact to Resolved and workflow to Resolved so service status returns to operational
• Scope services accurately — only mark services that are actually affected to maintain trust in your status page

Next steps#

• Subscribers — manage who receives incident emails
• Managing Services — configure the services incidents affect