The following page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features or functionality remain at the sole discretion of GitLab Inc.
This page outlines the direction for the Error Tracking category. Feedback is welcome: you can comment on the feedback issue or reach out to this page maintainer if you have any questions or suggestions.
With Error Tracking, developers can identify and visualize errors (also known as exceptions or defects) triggered by end users while using their applications. It enables development teams to centralize all errors in one place for triage and resolution. And by integrating debugging workflows into their existing DevOps platform, it eliminates the need for context-switching between multiple tools and reduce loss of information.
|Uses Sentry SDK to collect errors from major Back-end and Front-end programming languages.
|Error Grouping (Fingerprinting)
|Aggregate individual 'Error Events' experienced by multiple users into a single 'Error'.
|View Stack Trace
|Visualize the source code responsible for the error, accompanied by a comprehensive list of method calls.
|Display all errors in a centralized, searchable list with triage options: ignore, resolve, or create an issue.
|Filter by labels
|Not yet available
|Filter errors via user-defined labels such as 'environment' (dev or production)
|Not yet available
|Automatically create alerts for new errors, to notify a user or a Slack
Our objective is to increase developers' productivity by reducing the time they spend on identifying and resolving application errors, leveraging the GitLab platform to provide a superior experience to existing point solutions.
To accomplish this and reach a viable level of maturity, we will focus on developing three strategic axes:
Close the loop between development and production
GitLab is already the place where developers build, test, and deploy code changes. By feeding production errors back into these workflows and linking errors to a particular commit, MR or release, we will enable developers to further "shift-left" production debugging, and tackle these issues more efficiently. To achieve that, we are considering integrating errors within existing IDE extensions, source code management, planning/issues and CI/CD pipelines UI.
Provide end-to-end visibility for troubleshooting
By integrating with other telemetry data, error tracking will serve as an entry point to troubleshoot and dive deeper into related logs, metrics, or traces to find the root cause of the issue faster. To achieve that, we are considering replacing Sentry SDK by a collection system based on OpenTelemetry.
Automate resolution with suggested fixes
By managing source code and integration/deployment workflows, GitLab has a unique knowledge of applications. We aim to leverage these insights to offer automated suggestions or directly apply fixes when new errors are detected. This will further reduce or eliminate the need for manual intervention in error resolution. See related experiment.
Error Tracking is now Generally Available for SaaS (16.0 - 2023-05-22)
Learn more: Release Post
Currently (as of December 2023), the Observability Group is focused on other categories. As we progress on our 1 year plan, we will be able to redirect engineering effort on further improving Error Tracking.
We will know we are on the right trajectory for Error Tracking when we are able to observe the following: