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

Category Direction - Error Tracking

Introduction and how you can help

Thanks for visiting this category page on Error Tracking in GitLab. This page belongs to the Respond group of the Monitor stage, and is maintained by Alana Bellucci who can be contacted directly via email. This vision is a work in progress and everyone can contribute. Sharing your feedback directly on issues and epics at is the best way to contribute to our vision. If you’re a GitLab user and have direct knowledge of your need for error tracking, we’d especially love to hear from you.


Error Tracking is the process of proactively identifying application errors and fixing them as quickly as possible. Errors are often plentiful, noisy, and challenging to dig through to find the important ones that are impacting users. The best tools provide sorting and filtering by a variety of error attributes, information regarding the commit that likely caused the error, a detailed stack trace, and a set of useful actions such as ignore or resolve that help users to clear out errors they no longer need to pay attention to.

At GitLab, this functionality is based on an integration with Sentry which aggregates errors found by Sentry, surfaces them in the GitLab UI, and provides tools to triage and respond to the critical ones. GitLab leverages Sentry's intelligence to provide pertinent information such as the user impact or commit that caused the bug. Throughout the triage process, users have the option of creating GitLab issues on critical errors to track the work required to fix them, all without leaving GitLab.

In 14.4 we introduced Integrated Error Tracking. This is a lightweight alternative that leverages the Sentry SDK. With Integrated Error Tracking you don't need to deploy Sentry or set up for cloud-hosted Sentry. Instead, you use GitLab as the backend.

At a 30,000 ft view, adding Error Tracking to GitLab drives the single app for the DevOps lifecycle vision and works to speed up the broader DevOps workflow. We can eliminate an additional interface from the multitude of tools Developers are required to use each day to do their jobs. Furthermore, GitLab has the opportunity to surface errors early and often in the development process. By surfacing errors caused by a particular commit, merge request, or release, we can easily prevent our user's customers from experiencing the bug at all. GitLab's ownership of the development workflow makes it simple to remove additional interfaces from the tool chain which will decrease time spent and increase throughput.


Our vision is to surface important errors, reducing the time spent triaging, responding and remediating errors, all within GitLab.

Target audience and experience

The primary persona for Error Tracking is Sasha the Software Developer. Tracking and triaging errors is a part of any release process and the individual most qualified to solve the error is the developer who wrote the code. Secondarily, we've aimed our Error Tracking offering at Devon the DevOps Engineers who uses Error Tracking to investigate spikes in errors in production.


Maturity Plan

This category is currently at the minimal maturity level, and our next maturity target is viable (see our definitions of maturity levels).

What's Next & Why

As of now (January 2021), we are not actively working on Error Tracking while we make other categories in GitLab equally as awesome (check out Incident Management). Once we determine what comes next for error tracking, we will add more detail to this section. If you wish to contribute to the next features and improvements we work on, please take a look at the Error Tracking and Error Tracking, like Sentry backend but inside GitLab epics.

User Success Metrics

We will know we are on the right trajectory for Error Tracking when we are able to observe the following:

Competitive Landscape

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