Status Page MVC Discovery
Purpose
This issue captures the discovery/design plan for Status Page MVC, as well as, associated references and artifacts.
Overview
Incidents and outages inversely affect business stakeholders. While the response team mobilizes in the fire-fight, there is a demand from stakeholders to understand what happened, what the status of the incident is, and how it is progressing. These stakeholders may be executive leadership at the company internally or it's customers. The ability to manage external communications simply and efficiently is important so that the effort does not detract from the fire-fight to restore services.
Who is this for?
The primary use case for the Status Page MVC in the GitLab Infrastructure team. The solution will enable them to use ops.gitlab.net to manage incidents. This domain is private to protect critical systems and data meaning it is not public like GitLab.com. Using a public status page to publish incidents, the team can use a prviate instance to manage incidents while maintaining transparency of the incident issues with the public.
What problems are we trying to solve?
- Stakeholders need access to the incident issue description and important comments that share information about what is happening, changes in progress/status. The description includes all written detail, embedded metrics charts, and embedded images/screenshots.
- Responders (users who are working incidents and updating the status page) need a way to publish information to the status page from within GitLab
- Customers need a way to engage GitLab with inquiries. They will no longer be able to comment on the GitLab incident issue directly, so they must be provided a communication channel.
Plan
-
Synchronous kick-off meeting with stakeholders, product, UX, and engineering counterparts on Monday February 3rd -
Define minimally required user journey in MURAL -
Second sync on Thursday February 7th with engineering -
Design reviews with stakeholders
Deliverables
-
Detailed user Journey in Mural -
Mocks linked in MVC epic description (Status page MVC) -
Feature epics created for MVC solution linked to Status page MVC - each feature epic will then be broken down into granular implementation issues
WIP Design Proposal
MVC Designs:
Landing page | Incident detail page |
---|---|
![]() |
![]() |
Longer-term vision for landing page (when we deprecate status.io):
Landing page | Landing page, active incident | Incident detail page |
---|---|---|
![]() |
![]() |
![]() |
For the MVC:
- All issues created within an incident project will be pushed to a new status site
- We will display a simple list of all of the incident issues. Since pagination will not be included in the MVC, we can limit this page to show last 20 incidents.
- For a first pass, there would be no sorting of active/closed incidents. But, we can address this piece in future as part of a "full incident history" page.
- Clicking on the "full report" button on the incident landing page would open up the incident details on a separate page.
- The incident detail page will contain the issue description (including jpg/png images, if possible), the timeline, and issue comments. NOTE: not all issue comments will be published automatically to the status site. We'd like to utilize #2459 (closed) when it is built. In the interim, we may need to utilize a stop-gap measure, such as we'll only push comments with a specific emoji attached to them.
Still TBC: how we will determine which comments will be published and which will not. We may be able to utilize something similar to #2459 (closed), depending on how/when those are being built.