Incidents in Incident Response

Plan ahead of service disruptions and have Incident Response send messages, create status pages, and conference bridges immediately when incidents occur. Distractions are minimized and teams stay focused on remediation.

Create incidents within Incident Response using different sources, such as:
  • Automatically from Alert Rule Actions
  • Manual creation from an alert
  • Manual creation from the incident list view
The Assigned to and Responder list fields on an incident specify who should be notified. When a team is selected as a responder, team rules are checked to determine which schedule to use for the notifications. An incident can be assigned to multiple teams. Responders are notified according to their notification preferences.

The Assigned to field is cleared when the Assigned-team or Service field is updated on an incident. Escalation policies for the newly assigned teams run. The field remains cleared until a user on the new team acknowledges an escalation notification.

If the Service is changed and the new Service does not have an assigned team, no changes occur.

When a Service is deleted, its integrations, alerts, incidents, and automation rules are removed. This is not a recoverable action so consider deactivating the service instead.

Responders and above are notified for updates to incidents based on their notification preferences. If you made the update, you won't be notified. See Profile management. Stakeholders do not have notifications preferences, so they are sent an email, by default.

You can resolve incidents by selecting specific incidents or in bulk.

Incidents in the Resolved state are automatically closed after 3 days.

For more information on the areas and fields available in an incident, see Incident workspace.

You can export your incident data to a comma-separated values (CSV) file. See Export incident information to a CSV file for more information.