Introduction and how you can help

Thanks for visiting this category strategy page on Status Page in GitLab. This category belongs to the Health group of the Monitor stage and is maintained by Sarah Waldner E-Mail.

This strategy is a work in progress, and everyone can contribute:

Please comment and contribute in the linked issues and epics on this page. Sharing your feedback directly on GitLab.com is the best way to contribute to our strategy and vision.
Please share feedback directly via email, Twitter, or on a video call. If you're a GitLab user and have direct knowledge of your need for a status page, we'd especially love to hear from you.

概要

A common need for many companies is to communicate the availability of a software service they provide. This could be to internal users, customers, or the general public. These will be collectively referred to as Stakeholders. A typical Status Page publicly lists services that it provides and the status of that service. It's main purpose is for Stakeholders to self-serve information to determine if a service is unavailable while internal teams work to restore services that have been disrupted. In the event there is an outage, the Status Page also provides explanation for the outages as well as any known timelines for restoration. Stakeholders generally have the option of subscribing to different services to be proactively alerted to changes in Status.

In an age where systems must be highly available and uptime is guaranteed on the order of six 9's, it's crucial that the time and effort of response teams are not wasted updating Stakeholders in multiple ways.

Mission

Our mission is to reduce MTTR for DevOps response teams by making it simple to keep business and customer stakeholders informed on incident status and progress.

Challenges to address

We are just beginning research cycles to validate the need and desire for a Status Page as part of GitLab's product offering in the Monitor Stage.

Once we have begun research efforts, it will be documented here.

Target Audience

A Status Page needs to make it simple to understand the state of services someone is a Stakeholder of and it must be easy to manage and update internally. The target audience of Status Page can be divided into the following categories:

Users are in charge of maintaining the critical services that their stakeholders depend upon. They are responsible for updating the Status Page during outages.

Buyers manage the teams who maintain the software services the company provides to customers.

Consumers are the Stakeholders that care about the availability of provided software services. These individuals can be internal or external, individual contributors, management, or customers.

戦略

Maturity Plan

This category is currently at the Planned maturity level, and our next maturity target is Minimal (see our definitions of maturity levels). Please check out the MVC for Status Page.

Where we are headed

Our vision is to build a portal for maintainers and Stakeholders that is simple to update, easy to consume, and has a customizable UI. A mature Status Page contains a list of services provided, description, and status as well as the ability for stakeholders to subscribe to notifications on services as there are changes.

GitLab is in a unique position to offer compelling value here:

We can generate alerts based on a wide array of observability data: metrics, traces, and logs.
We can consume alerts from any monitoring tool via our generic alert endpoint
We are adding comprehensive Incident Management in 12.6
GitLab has a decentralized runner architecture which can run tests from across the world (or via a potential SaaS service) to detect reachability problems
We have an opportunity to dogfood this tool with our GitLab.com service. In our past we've used a home-grown tool for a Status Page service, and since switched to a SaaS provider.

What's Next & Why

We've planned an initial minimal release of Status Page for 12.10. To begin with, we are targeting one narrow use case. We'll design Status Page to publish information from issues in a dedicated incident management project on a private GitLab instance out to public status detail pages. We believe in dogfooding everything. The initial MVC will enable the GitLab SRE team to start using Status Page and by extension unblock them from dogfooding several monitor capabilities.

See what's planned and what's shipping in 12.10 in the Status Page MVC epic.

What is Not Planned Right Now

Scope of work and timeline for Status Page is still being determined at this time. After further research, we will populate this section with functionality that is out of scope.

User success metrics

We will know we are on the right trajectory for Status Page when we are able to observe the following changes. Please note that these metrics are based on our vision for the product and may change as we start working on it.

GitLab can replace the it's current status page hosted on status.io (i.e. we are dogfooding)
Increase in status update subscribers
Increase in the number of services a given customer integrates into the page

Why is this important?

Managing stakeholders is an important part of the job for any DevOps engineer and a Status Page has become a critical part of the services a software company provides to their customers. It provides a public portal for broad communication during an outage. It helps to reduce the number of related support tickets that come pouring in or the negative blasts on social media. Updating a single portal is much faster than responding to individual inquiries from each customer. This is a natural addition to the GitLab product suite on top of our Incident Management offering. It eliminates yet another integration and additional tool.

At this time, we have not completed due diligence to confirm this is the most pressing functionality to add to the Monitor Stage. Further research and validation is required to confirm that we will be investing in a GitLab hosted Status Page. A fully featured Status Page would likely take 4-5 milestones to build.