Allow more granular control over which issues create incidents on Status Page
We should look at filtering which issues we add the Status Page.
Right now, the behaviour is (once the Status page settings have been setup) to sync all non confidential Issues as an Incident to the Status Page. This works well when a separate Project is setup for the Status Page issues, but it still has some flaws.
- It doesn't let people collaborate on issues before syncing to Status Page & creating an open incident
- If Issues are pre-existing it will send them all to the Status Page
Proposal
- Allow users to publish and unpublish an incident to the status page using quick actions:
/publish
and/unpublish
. - The quick action will only successfully publish to the status page only if the user is a project owner
- After completing the quick action, we will immediately notify users whether or not their actions were successful using quick action alert messaging (see visual examples below).
- When the commands to publish or unpublish successfully execute, introduce a system message confirming the quick action on the issue (see visual examples below).
- When the status page is published, utilize the pinned embed pattern to link directly to the published incident's detail page (see visual examples below). #213913 (closed), #213914 (closed)
- The "unpublish" piece of this functionality can be added as part of a separate iteration if/as needed. #212735
Visual examples:
Actions and messaging visuals | Pinned embed visual |
---|---|
![]() |
![]() |
Original Proposal
We can use a label, such as Status Page::Incident
to specify which Issues to treat as incident issues. Or Maybe we can add
This makes the action of syncing to Status Page intentional & allows some powerful behaviour:
ex:
- SRE 1 creates an issue but doesn't want to make it public yet.
- SRE 2 and SRE 1 collaborate on the Issue to provide enough detail.
- When happy, they apply the label to indicate the Issue should be synced to status page.
Having a label allows you to select Issues to backfill the Status Page, while keeping unrelated Issues within GitLab only.
The effort is pretty minimal to scope Issues by a label in the backend & just involves a join onto the Label
table.
Requirements
- Need a way to promote an issue to "publishing to status page"
- Need to make it clear that an issue is published
- Need to make sure that only the correct people can promote (SREs only)
- Unless an incident is locked, all users on
ops.gitlab.net
should be able to contribute to the ongoing incident with comments and emoji reactions. So, whatever approach we utilize shouldn't otherwise impact these interactions. - Update usage ping for Number of issues published to Status Page site to account for filtering
Permissions and security
For the ops.gitlab.net use case, only SREs should be able to publish issues. We will restrict to this group by utilizing the project's owners. Only project owners will be able to publish/unpublish an issue to the status page.
The desired outcome for permissions includes whatever mechanism is used to publish an issue, if you see that mechanism in place then you can be confident that the issue is published.