Gitlab hero border pattern left svg Gitlab hero border pattern right svg

Product Direction - Monitor

On this page

This is the product direction for Monitor. If you'd like to discuss this direction directly with the product managers for Monitor, feel free to reach out to Sarah Waldner (PM of the Health Group) (GitLab, Email Zoom call) or Kevin Chu (Group PM of Monitor) (GitLab, Email Zoom call).


The Monitor stage comes after you've configured your production infrastructure and deployed your application to it.

  1. The Monitor stage is part of the verification and release process - immediate performance validation helps to ensure your service(s) maintain the expected service-level objectives (SLOs) for your users.
  2. The Monitor stage is an observability platform. Observability is the ability to infer internal states of a system based on the system’s external outputs. Whether there are known ways to understand the total health of your systems, or your complex microservices system is full of unknowns, we want you to be able to export your system's product analytics to GitLab and use it to debug and diagnose any potential problem.
  3. The Monitor stage helps you respond when things go wrong. It enables the aggregation of errors and alerts to identify problems and to find improvements. The Monitor stage also enables responders to streamline incident response, so production issues are less frequent and severe.
  4. The Monitor stage also provides is user feedback. Understanding how users experience your product and understanding how users actually use your product are critical to making the right improvements.


The mission of the GitLab Monitor stage is to provide feedback that decreases the frequency and severity of incidents and improves operational and product performance.

The categories within the Monitor stage fits together to support the mission in the following way:

stateDiagram Development --> Monitor: Code Deploy state Monitor { s1 --> s2: Daily Operations s2 --> s3: Incident s3 --> s4: Resolution s2 --> s4 s1: Verification s1: Metrics s1: DEM (Synthetics) s1: DEM (Web Performance Monitoring) s2: Observability s2: Metrics s2: Traces s2: Logs s2: Errors s3: Response s3: Incident Management s3: Observability s4: Feedback s4: DEM (Real User Monitoring) s4: Product Analytics } Monitor --> Development: Continuous Improvement


The Monitor stage directly competes in several markets, including Application Performance Monitoring (APM), Log Management, Infrastructure Monitoring, IT Service Management (ITSM), Digital Experience Management (DEM) and Product Analytics. The total addressable market for the Monitor stage was already more than $1.5 billion in 2018 and is expected to grow as businesses continues to shift to digital.

All of these markets are well-established and crowded. However, they are also being disrupted by the underlying technologies used. The shift to cloud, containers, and microservices architectures changed users' expectation, and many existing vendors have struggled to keep pace. Successful vendors, such as market leader Datadog have leveraged a platform strategy to expand their markets (such as the acquisition of Undefined Labs to expand beyond production applications to provide code insights during development, or their expansion to incident management in 2020), and even stages within DevOps. Competition among market leaders today is also geared toward making the whole stack observable. New Relic's updated business model reflects the need for vendors to capture increasing footprint (and spend) of enterprises while enabling future growth by making a significant part of their business free.

There is also an emerging recognition for the need for an integrated platform when it comes to your Monitoring capabilities. Existing players and new entrants like Fyipe are pursuing this integrated platform approach.

The changes in the market have also revealed opportunities that new entrants into this stage, like GitLab, can take advantage of. Specfically, the Ops section opportunities worth re-emphasizing are:


The Monitor stage follows GitLab's product principles and the Ops section themes, and also has a few others to ensure we focus on the right experiences for our users.


The vision of the Monitor stage is to enable DevOps team to operate their application by enabling verification, observability, incident response, and feedback all within GitLab. This vision is part of the overall GitLab vision and enables teams to complete the DevOps loop.

GitLab is uniquely qualified to deliver on this bold and ambitious vision because:

  1. GitLab is a complete devops tool that is connected across the devops stages. Being one tool makes the circular devops workflow, and feedback, seamless and achievable.
  2. The Monitor stage is pursuing a differentiated strategy from other observability vendors by not pursuing a usage based model business model by charging for processing and storage of observability. Instead, we lean on powerful open source software, such as Prometheus and OpenTelemetry, along with commodity cloud services to enable customers to setup and operate Monitor stage observability solutions effectively. We will be successful because we are well-practiced in integrating different parts of the tool chain together.
  3. Going cloud-native is a disruption to operations as usual. Cloud-native systems are constantly changing, are ephemeral, and are complex. As more and more companies adopt cloud-native, GitLab can create a well-integrated central control-pane that enables broad adoption by building on top of the tools that cloud-native teams are already familiar with and are using.

A trade-off in our approach is that we are explicitly not striving to be a fully turn-key experience that can be used to monitor all applications, particularly legacy applications. Wholesale removing an existing monitoring solution is painful and a land and expand strategy is prudent here. As a customer recently explained, "Every greenfield application that we can deploy with your monitoring tools saves us money on New Relic licenses."

As this stage matures, we will begin to shift our attention and compete more directly with incumbent players as a holistic Monitoring solution for modern applications.


To achieve our vision, our strategy is to:


Monitor is a critical component for all software development and operations. The Monitor stage's tier strategy will be broken down by workflow as described below.


To execute our land and expand strategy and to receive as much feedback from our potential user base, Core contains the vast majority of the Monitor features, including metrics, logs, incident management, traces, and error management.



Upcoming starter Monitor functionality include:


Upcoming premium Monitor functionality include:


Upcoming ultimate Monitor functionality include:

What's next

The Monitor surface area is large. Rather than continue to pursue bringing multiple products within the monitor purview to market concurrently, GitLab has consolidated its focus to Incident Management. This allows us complete the smart feedback loop within a single DevOps platform as a first priority. With GitLab Incident Management's development timeline, our users will benefit from the advantage of enabling collaboration for incident response within the same tool as their source code management, CI/CD, plan, and release workflows - all within the same tool. This most effectively positions GitLab to gain market traction and user adoption. As of September, 2020, we are not actively developing any of our Observability capabilities which include Metrics, Logging, and Tracing.

The Monitor stage's goals from 2020-11 through 2021-01 are the following:

  1. Mature the Incident Management category so that the GitLab SRE team can dogfood it
  2. Grow estimated SMAU for Monitor to 12,000 users

You can see our entire public backlog for Monitor at this link; filtering by labels or milestones will allow you to explore. If you find something you're interested in, you're encouraged to jump into the conversation and participate. At GitLab, everyone can contribute!

Performance Indicators (PIs)

Our Key Performance Indicator for the Monitor stage is the Monitor SMAU (stage monthly active users).

Monitor SMAU is determined by tracking how users configure, interact, and view the features contained within the stage. The following features are considered:

Configure Interact View
Install Prometheus Add/Update/Delete Metric Chart View Metrics Dashboard
Enable external Prometheus instance integration Download CSV data from a Metric chart View Kubernetes pod logs
Enable Jaeger for Tracing Generate a link to a Metric chart View Environments
Enable Sentry integration for Error Tracking Add/removes an alert View Tracing
Enable auto-creation of issues on alerts Change the environment when looking at pod logs View operations settings
Enable Generic Alert endpoint Selects issue template for auto-creation View Prometheus Integration page
Enable email notifications for auto-creation of issues Use /zoom and /remove_zoom quick actions View error list
  Click on metrics dashboard links in issues  
  Click View in Sentry button in errors list  

See the corresponding Periscope dashboard (internal).


There are a few workflows that are critical to our users in this stage.

Each of these workflows has a designated level of maturity; you can read more about our category maturity model to help you decide which categories you want to start using and when.

Monitoring - Instrument

This workflow is planned, but not yet available.

Monitoring - Triage

Starting with the highest level alert, using preconfigured dashboards to review relevant metrics, enabling ad-hoc visualization and immediate drill down from time sliced metrics into logs and traces in the same screen This workflow is planned, but not yet available.


Monitoring - Resolve

This workflow is planned, but not yet available.

Monitoring - Improve

This workflow is planned, but not yet available.


There are a few product categories that are critical for success here; each one is intended to represent what you might find as an entire product out in the market. We want our single application to solve the important problems solved by other tools in this space - if you see an opportunity where we can deliver a specific solution that would be enough for you to switch over to GitLab, please reach out to the PM for this stage and let us know.

Each of these categories has a designated level of maturity; you can read more about our category maturity model to help you decide which categories you want to start using and when.


Runbooks are a collection of documented procedures that explain how to carry out a particular process, be it starting, stopping, debugging, or troubleshooting a particular system. Executable runbooks allow operators to execute pre-written code blocks or database queries against a given environment. This category is at the "minimal" level of maturity.

Priority: low • DocumentationDirection


GitLab collects and displays performance metrics for deployed apps, leveraging Prometheus. Developers can determine the impact of a merge and keep an eye on their production systems, without leaving GitLab. This category is at the "viable" level of maturity.

Priority: high • DocumentationDirection

Incident Management

Track incidents within GitLab, providing a consolidated location to understand the who, what, when, and where of the incident. Define service level objectives and error budgets, to achieve the desired balance of velocity and stability. This category is at the "viable" level of maturity.

Priority: high • DocumentationDirection


GitLab makes it easy to view the logs distributed across multiple pods and services using log aggregation with Elastic Stack. Once Elastic Stack is enabled, you can view your aggregated Kubernetes logs across multiple services and infrastructure, go back in time, conduct infinite scroll, and search through your application logs from within the GitLab UI itself. This category is at the "viable" level of maturity.

Priority: medium • DocumentationDirection


Tracing provides insight into the performance and health of a deployed application, tracking each function or microservice which handles a given request. This makes it easy to understand the end-to-end flow of a request, regardless of whether you are using a monolithic or distributed system. This category is at the "minimal" level of maturity.

Priority: medium • DocumentationDirection

GitLab Self-Monitoring

Self-managed GitLab instances come out of the box with great observability tools, reducing the time and effort required to maintain a GitLab instance.

Priority: low • DocumentationDirection

Error Tracking

Error tracking allows developers to easily discover and view the errors that their application may be generating. By surfacing error information where the code is being developed, efficiency and awareness can be increased. This category is at the "viable" level of maturity.

Priority: low • DocumentationDirection

Product Analytics

This category is planned, but not yet available.
Priority: medium • DocumentationDirection

Synthetic Monitoring

Proactively simulate, monitor, and report on success rates and executions for user actions and behavior pathways. This category is planned, but not yet available.

Priority: high • Direction

Upcoming Releases

13.7 (2020-12-22)

13.8 (2021-01-22)

13.9 (2021-02-22)

Other Interesting Items

There are a number of other issues that we've identified as being interesting that we are potentially thinking about, but do not currently have planned by setting a milestone for delivery. Some are good ideas we want to do, but don't yet know when; some we may never get around to, some may be replaced by another idea, and some are just waiting for that right spark of inspiration to turn them into something special.

Remember that at GitLab, everyone can contribute! This is one of our fundamental values and something we truly believe in, so if you have feedback on any of these items you're more than welcome to jump into the discussion. Our vision and product are truly something we build together!

Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license