- Status: MVC1 (&2479) and MVC2 (&2681) released, but no further development is pending after %13.1 - Tier: ~"GitLab Ultimate" - Docs: https://docs.gitlab.com/ee/operations/incident_management/status_page.html ### Problem to be Solved #### Context Today, response teams typically need to juggle multiple tools during a firefight with one place for internal team collaboration and a separate place to notify stakeholders of the incident status. The overhead in moving information from one tool to another takes extra time right at the very moment when time is most precious and needed to resolve the incident. Some incident-tool-to-status-tool integrations exist, but they are not for every tool. The process of manually copying and pasting information between tools introduces the risk of human error where inaccurate information can be disseminated. 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. Making an incident issue tracker public is one way to allow the general public to consume information as the response team posts it. However, there are many reasons companies do not wish to make their issue trackers public. Not many companies maintain the level of transparency that GitLab does and often they want to tightly control the information that is disseminated publicly with a dedicated space for public information. Additionally, pointing your entire customer base to your issue tracker during an incident means that your GitLab instance needs to be operationalized to handle the load for a massive increase in user traffic. This typically isn't cost-effective for most organizations. A stand-alone status page can function as a dedicated space to post public information that can be designed to handle the necessary traffic loads. If a user's GitLab instance is not accessible to their business stakeholders, then that user requires a way to externally communicate about incidents separate to GitLab. The goal of this epic is to create a portal where responders can automatically and manually post up-to-date information on incidents. #### Problem Summary 1. 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. 2. Responders (users who are working incidents and updating the status page) need a way to publish information to the status page from within GitLab 3. 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. ## Why GitLab? GitLab is in a unique position to offer compelling value here: 1. We can generate alerts based on a wide array of observability data: metrics, traces, logs, and blackbox monitoring 1. We are adding comprehensive Incident Management: https://gitlab.com/groups/gitlab-org/-/epics/349 1. GitLab has a decentralized runner architecture which can run tests from across the world (or via a potential SaaS service) to detect reachability problems # Proposal  We can start down this road by: - [ ] Build a public page to surface this information cleanly, similar to GitLab Pages but able to deliver live data like charts and incident information - [ ] Integrate with Incident Management, to allow an Ops person to acknowledge and incident and publish status. (If unacknowledged for X minutes, perhaps auto-publish.) - [ ] Once published, make it easy to update directly from the incident. - [ ] Display an availability chart for each service. - [ ] Depending on demand, consider providing a SaaS service for the status page hosting as well as worldwide blackbox monitoring services