Working with Incidents

When a Bolstat check fails, it will trigger an alert. These alerts will create incidents based on your incident aggregation policy. Incidents notify you about something that went wrong and allow you to manage it.

Incident Lifecycle

Incidents evolve along the following lifecycle:

Open: An incident starts in the open status. During the open status Bolstat will try to alert you team about this incident.

Acknowledged: When someone acknowledges the incident, any escalation and notifications to other team members will pause so the team member handling the incident can manage it.

Resolved: After the issue has been fixed, the incident will close and take the resolved status.

Severity Levels

Every incident can have one of three different severity levels:

Critical: Critical incidents are meant to alert you about your most critical infrastructure components. These incidents will escalate throughout your whole team and will use all their notification methods.

Minor: Minor incidents are important, but not time-sensitive. The first step within your notification policy will be triggered, but not escalated to other team members. Team members can also set their own contact preference for these incidents.

Info: Info incidents are meant to inform only. Team members will not receive any notifications about these. Only the dashboard and integrations like Slack will show the incidents.

Incident Aggregation

Alerts are aggregated by default per check. This means that multiple alerts from one check will be grouped in one incident. You can choose to adjust this and aggregate per project, component or check. It is also possible to disable aggregation by choosing the “Alert” level.

Aggregation Override

It is possible to override the global aggregation settings per check. This allows you to make sure one important check still creates a separate incident per alert or to still aggregate a noisy check while the global settings create an incident per alert.