Design discovery: Slack integration for incidents

Release notes

What do we want to know?

We have an existing Slack integration, and some of the features can be used for incidents. However, that integration is currently being updated, and we're not sure if/how those updates will support incident responders. Further, our SRE team has created their own Slack integration for incidents, called Woodhouse. The current state leaves us with a lot of questions about how to better support incident responders who are using Slack within GitLab, like:

• Will incident responders be adequately supported by the updated GitLab Slack integration?
• Should we use - or build on top of - the GitLab Slack application for incidents?
• Should we instead "productize" some version of Woodhouse for incident responders?
• Should we continue incrementally updating what we have?

Because there are so many outstanding questions, it's difficult to determine how to proceed with making improvements to the Slack-to-GitLab workflow for incident management, which is likely something that will be important to increase adoption of incidents.

Let's use this issue to pin down what we know, and don't know, by outlining the current incident management functionality, the current woodhouse functionality, and the planned Ecosystem Slack integration updates. Once we've outlined all three of these these things, hopefully the path forward for a tighter Slack-to-GitLab integration for incident management will be clearer. The larger goal for this issue, then, is to define how the Respond team will move forward with improvements to the Slack integration for incidents.

What have we learned?

1. Current incident management slack functionality --> Outlined in this thread
2. Current Woodhouse slack functionality --> Outlined in this thread
3. Planned ecosystem slack integration features --> Outlined in this thread

Workflow for Slack:

More information about the workflow in this thread.

What should we do next?

By focusing on the items in green in the workflow diagram above, we can improve the existing Slack workflow for incident response by introducing/shoring up the ability to:

1. Define Slack notification settings for incidents
2. Declare an incident from Slack, and include options to
   • Add relevant information to the incident from Slack at the time of incident creation (following Woodhouse).
   • Add appropriate additional resources to the incident at the time of incident creation (zoom link, create new Slack channel, again following Woodhouse).
   • Post a notification of incident creation in the appropriate Slack channel, with links to the relevant resources (following Woodhouse).
   • Post relevant resources that have been added to the incident issue (following Woodhouse).
3. Keep content synced up between Slack and GitLab

In practice, that could look like this:

Create a space to define incident notification settings	Allow people to create an incident from Slack	Allow for adding data to incidents at the time of incident creation	Post a notification linking to relevant resources in Slack when an incident has been created	Add relevant details from Slack directly to the incident	Find a way to send updates to Slack from GitLab	Refine process for adding Slack comments to incidents	Introduce a way to add items to the timeline from Slack

Our goal would be to build on the improved GitLab Slack app the Ecosystem is building. However, if the notifications haven't yet been ported over to the GitLab Slack app yet, we may need to build on the current GitLab Slack notification integration. More details in this thread.

Figma file

Intended users

Feature Usage Metrics

This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.