Design Discovery: Surface Alerts in GitLab
Problem to solve
Many of our SMB customers are getting alerts from multiple sources. These alerts are primarily going into Slack or are being emailed to them. Managing these alerts from different sources, and that are being received in different places, is burdensome. It also means that, when they want to elevate these alerts to incidents, there is no easy way to do so. They have to manually create incidents in GitLab, and manually copy all the information over to the GitLab incident.
We should streamline this workflow, so that all the alerts can come directly to GitLab. If we do that, users can manage all alerts, escalate them into an incident, and resolve the issues in their code all within one tool.
Intended users
Further details
Proposal
As part of this investigation, we should:
-
Outline the workflow to make sure we have a plan for each piece (ex, will our existing generic alert endpoint work to receive the alerts that we want to surface? If we are surfacing the alerts in GitLab, how will we broadcast those alerts out to the proper channels?) -
Investigate what competitors in the space are doing for surfacing alerts in their tools (ex, Splunk alert manager, BigPanda, MoogSoft, Ops genie) -
Create designs for a MVC version of the alert manager within GitLab -
Test designs with users -
Attach designs to issues for 13.0
Design
Initial empty state | Configuration screen (already exists in the UI - some copy updates) | Alerts list view | Alerts detail view | Alerts detail view - additional tab | Issue created from alert |
---|---|---|---|---|---|
The severity markers are currently those in use on the Security Dashboard. The icons are already available in GitLab SVG, and we could follow the colors outlined as part of #34352 (comment 275293318) to denote severity of alerts:
Permissions and Security
Documentation
Availability & Testing
What does success look like, and how can we measure that?
What is the type of buyer?
Links / references
Competitive research mural board