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 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 Kevin Chu (Group PM of Monitor) (GitLab, Email Zoom call).
The mission of the GitLab Monitor stage is to provide feedback on the health and performance of your system so that you can decrease the frequency and severity of incidents.
The Monitor stage directly competes in several markets defined within our Ops Section, 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 is projected to be $2.7 billion by 2024.
All of these markets are well-established and crowded, with winning companies achieving spectacular growth as businesses continue to shift online.
Successful vendors, such as market leader Datadog are leveraging a platform strategy to expand their markets (see DataDog's acquisition of Undefined Labs to expand beyond production applications to provide code insights during development, or their expansion to incident management in 2020). Competition among market leaders today is also geared toward making the whole stack observable for enterprises. 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.
The vision of the Monitor stage is to enable DevOps team to operate their application by enabling monitoring, observability, incident response, and feedback all within a single application, GitLab.
Everyone needs monitoring. We want everyone to be able to access it, without an exorbitant cost that constantly needs to be monitored, and without specialized skills to use the tools in order to get the benefit. In short, we would like Monitoring to be commoditized and democratized.
To achieve our vision, our strategy is to:
The Monitor surface area is large. Rather than continue to pursue bringing multiple products within the monitor purview to market concurrently, GitLab has consolidated the majority of its current focus to Incident Management. This allows us to 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.
The details of what the Monitor Group is currently working on is listed in Incident Management Direction.
GitLab users previously can monitor their services and application by leveraging GitLab to install Prometheus to a GitLab managed cluster. Similarly, users can also install the ELK stack to do log aggregation and management. The advantage of using GitLab with these popular tools is that users can collaborate on monitoring in the same application they use for building and deploying their services and applications. Furthermore, developers, who do not use, or potentially because they don't have access to their organizations monitoring tool, seeing metrics for their service and cluster metrics where their application run is extremely useful.
However, we believe that our solution is niche and reliant on a foundation that will be removed as we are deprecating GitLab Managed Apps.
What we've learned since that makes this particular strategy challenging are the following:
The Monitor SMAU is based on the Incident Management category. It is the count of unique users that interact with alerts and incidents. This PI will inform us if we are on the right path to provide meaningful incident response tools.