Roadmap epic: https://gitlab.com/groups/gitlab-org/-/epics/18072+ Dashboards are a core piece of any analytics workflow. Customers use them to track a variety of things from customer behavior to service health to team productivity/output. GitLab is striving to allow customers a single place to ask questions of their data, source agnostic, so that they can truly connect their code, delivery, health, and customer outcomes in a single, unified visualization. In order for us to achieve that vision, it is critical that we build the core, table stakes features that customers rely on in their current tools (be that PA or observability vendors) to create custom dashboards. This epic will include the list of those core features, along with the competitive intel associated with each so that we may form a roadmap and design vision that gets us closer to the parity we need in order to encourage our customers to use GitLab as the single source of truth for all of their monitoring/analysis needs. And while we may have started with the use case of product analytics, and then moved to observability, the overarching goal is that there is one Dashboards landing space that is the SSoT for customers who wish to analyze any of the data sources within GitLab's ecosystem, be it pipeline trends or AI impact. The experience should feel seamless and well integrated into the platform, meaning customers aren't exposed to the intricacies of each data source, only that they have one space that allows them to query, ask questions of, and analyze the output of everything in GitLab. We believe that by unlocking this use case, customers will no longer To get here, we started with our learnings from developing a framework tied heavily to Product Analytics, but are now moving to develop a global, scalable dashboard framework that allows users to query data from all internal sources at GitLab. Additionally, GitLab is iterating on building a [GitLab query language](https://handbook.gitlab.com/handbook/engineering/architecture/design-documents/glql/) and the data explorer will be a core use case to enable using the feature. ### What are the internal data sources in GitLab? Follow our [data unification efforts here](https://gitlab.com/groups/gitlab-org/architecture/gitlab-data-analytics/-/epics/3) - Optimize - Collects surfaces data about processes and features in GitLab that can be used to gain insight into the full DevSecOps lifecycle including team, development, deployment, and security efficiencies - Data collected is in the form of straightforward **metrics** (ex. value stream analytics) or more attribute-rich usage **events** (ex. AI Impact) - Dashboards in-product today include Value stream analytics, AI impact analytics, Productitivy analytics, Contributor analytics, etc - CI/CD - Provides a detailed look into the specifics around your continuous integration and deployment phases helping to identify issues quickly and resolve them faster. - Data collected here can include metrics, events, logs, and potentially even pipeline tracing (TBD) - Dashboards in-product today include CI/CD analytics - Secure - Track how well your team tracks on compliance and vulnerability management as code moves through the development lifecycle. - Collects lightweight metrics about security stats as well as more robust vulnerability and resolution data for various security testing processes (SAST, DAST, etc) - Dashboards in-product today include Vulnerability management, plans for Compliance reporting in FY26Q1. As new dashboard needs arise throughout GitLab, the Platform Insights team will be working directly with teams to ensure that they can be developed in the framework. Track information about the dashboards available [here](https://docs.google.com/spreadsheets/d/1dCJFJNKl0OF7OhOXR4FWNwLVUGUh71NxeimFjq1cTz0/edit?usp=sharing) as we iterate through the process of migrating and upgrading experiences into the unified dashboard framework. ### Where does AI come into the picture? As we evolve the dashboard data exploration feature, where data is the key to the deliverable, we should allow customers to use AI to help identify what they _should_ be exploring. This could include things like: * What queries should I explore for my team health and efficiency metrics? * What queries should I run to determine if my pipelines are healthy? * What queries should I run to create a dashboard for my high level team metrics for the full devsecops lifecycle? We can also help the users explore what data is available, allowing them to have an on-demand data dictionary that can help them understand what they have access to and what's possible for them to use when creating a dashboard. Examples: * What are the supported data sources at GitLab and what questions do they answer? * What metrics are available to explore for CI/CD analytics? In addition, as we roll out the data unification efforts and new GitLab-built reports, we must be able to validate that the metrics we are querying and reporting on should be accurate. Recently, team members have found that when they look at reports and then do manual calculations, the metrics are not the same. There is potential to use AI to determine areas of bad/insufficient/outlier data or problems with the way queries were structured so that they lead to inaccurate calculations. Let's crowdsource ideas from customers and [spike the "what's possible"](https://gitlab.com/gitlab-org/gitlab/-/issues/510159) as we investigate the connection to the data unification, unified data exploration query language, and visualization layer efforts. ### Table stakes features: - Streamline navigation so that one Dashboards option exists in the left navigation at both group and project levels. This will save users time when trying to locate where they would go to gain insight from their data. - Ability to query data from any source GitLab internal source in the MELT stack(metrics, events, logs, traces) - Improve Data Explorer to use a single query language to build queries and visualize data - Ability to filter data on Dashboards by something other than time - Ability to have panel-level filters - Ability for a user to store the desired time frame with each panel/query, decide whether to include or not in global filters - Deliver pre-built dashboards that the user can clone/edit * Migrate existing GitLab reports/views/dashboards into a single Dashboards navigation that uses the unified framework and allows customers a starting point for both building their own dashboards, but also a simple way to understand the existing data and the queries used to create common charts - Add tags/labels to dashboards for organization, filtering - [Clone any dashboard](https://gitlab.com/gitlab-org/gitlab/-/issues/461079) - Privacy controls on dashboards and on individual charts - - User can mark confidential or public, restrict access on view, edit, share, and delete (think PII or a dashboard that is business critical that only admin/maintainers/creator can delete) - Generate [Audit events](https://gitlab.com/groups/gitlab-org/-/epics/13699) for most CRUD events (edit, delete, share, download, etc) - CRUD - standard features as applicable - Share/download/embed chart images - Ability to take a chart from any area of the GitLab UI and Add it to a dashboard (save time for users, springboard them into building the views that are important to their team/use case - Ability to perform calculations on that data (count, sum, avg, median, percentiles, etc) in timeseries or single stat - Ability to plot multiple calculated data streams on a single chart (compare median, 75%, 95%) - Export/share dashboard (various options from pdf version to configuration json/yaml or csv for data within charts) - Advanced - Annotations/Overlays: big effort, high value (XL) - requires ability to overlap data from different sources onto one chart. Alerts, deployments, any event, pipeline failures, plot multiple environments, week over week, etc. - Import dashboards from another source to help with tool migration (import json configs in bulk from DataDog, as an example) - Panel level controls * Panel error handling and messaging (exists today, but should be improved) * Panel level filtering * Panel level min and max height and width standards * Panel level permissions - Explore and implement data exploration via a unified query language. Note that while GLQL is in it's infancy, the data exploration experience may be represented slightly differently in the UI to account for specificity associated with each data source. The ultimate goal would be that the user is eventually able to engage with a single, easy-to-understand query language that translates queries into visualizations regardless of source. #### Controls on the Dashboard List: - Search - Columns to display (Name, created date, created by, CRUD operation menu with Delete/clone options) - Sort by columns (at least name) - Potentially implement a user favorite option (stores with user ID), favorites would float to the top of the list - CRUD operations (create new dashboard, edit existing if not owned by GitLab, delete (may have some rules about user level), clone) - Clone creates a copy of the dashboard and config, user must supply a new name. Notes that user can clone a GitLab built dashboard which will remove the restriction on editing for the copy. - View what's available based on tier and user roles (example, AI Impact dashboard is only for Ultimate tier users) #### Create a new Dashboard features: - Data agnostic view to add new widgets (imagine we will have a slightly disjointed view for a bit here as different sources of data currently have different controls and use cases) - User has access to a list of common chart types/widgets (timeseries line, column, area, pie, single stat, multi-stat sometimes called Billboard, etc - see competitive options) - User controlled resizing and widget layout (**_already supported_**) - Import yaml/json config to create new dashboard - this could be a shared config from another tool or from another team within GitLab, should import the config to the correct project <table> <tr> <th>Feature</th> <th>Reason</th> <th>Status</th> <th>LOE</th> <th>Priority</th> <th>Milestone</th> <th>Delivered</th> </tr> <tr> <td> [Provide the ability to duplicate (clone) dashboard](https://gitlab.com/gitlab-org/gitlab/-/issues/461079) </td> <td>We supply some prebuilt dashboards for customers, however, they cannot edit these. By supplying a quick way that users can duplicate a dashboard, they can take the ones we supplied (or any they made) and not start from 0 when creating a new dashboard. This work will include a minor change to the dashboard list page to add the controls to duplicate a dashboard from that page.</td> <td>Ready</td> <td>Low (frontend)</td> <td>H</td> <td>17.3</td> <td> :white_check_mark: </td> </tr> <tr> <td>New dashboard list view with added controls</td> <td>As dashboards get more widely adopted, it will be necessary for users to have more visibility into characteristics of dashboards from the list view in order to find what they are looking for. They will need the ability to search and have quick controls directly from that page. We can do an iterative approach to this feature, but should start by adding created and last edited dates, user who created the dashboard, controls to duplicate, and a top level search bar.</td> <td>Design</td> <td>Medium-High (backend + frontend)</td> <td>M</td> <td>backlog</td> <td></td> </tr> <tr> <td>Advanced user permissions (CRUD)</td> <td>Because dashboards can be a critical part of a team's workflow, there need to be controls in place to prevent users from deleting or modifying a dashboard that they don't own (or didn't create.) This can be iteratively implemented, but also we will need to ensure that all actions are audited.</td> <td></td> <td></td> <td>M</td> <td>backlog</td> <td>Some items available with the duplication option</td> </tr> <tr> <td>Expand supported chart types (Echarts)</td> <td>Funnels, pie charts, etc are commonly used in items that we don't currently support.</td> <td>Ready</td> <td>Medium (frontend)</td> <td></td> <td>backlog (as needed)</td> <td></td> </tr> <tr> <td> [Provide support for a markdown widget/tile/viz](https://gitlab.com/gitlab-org/gitlab/-/issues/465840) </td> <td>This work will involve adding a tab to the viz designer that allows the users to input data (images/text/links) that will populate a tile on a dashboard.</td> <td>Design</td> <td>Low-Medium (frontend)</td> <td></td> <td>backlog</td> <td></td> </tr> <tr> <td>Improve dashboard edit flow</td> <td>Provides an improved dashboard editor experience where users can quickly add visualizations, modify queries, and create panel groupings without needing to navigate back to the dashboards list, nor will they need to select from a large library of pre-generated visualizations</td> <td>Needs Design</td> <td>Low (frontend + UX)</td> <td></td> <td>backlog</td> <td></td> </tr> <tr> <td> [Edit an existing visualization](https://gitlab.com/gitlab-org/gitlab/-/issues/433040) </td> <td>Users can only create new visualizations and when exploring their options this results in many files that clutter the UI. Editing will provide users a way to explore their options without creating new configuration files.</td> <td>Solution</td> <td>Low (frontend)</td> <td></td> <td>backlog</td> <td></td> </tr> <tr> <td>Create new Dashboards group/project level navigation</td> <td> While there currently exists an Analyze\>Analytics dashboards navigation, we feel this is too buried for the critical path workflow of data exploration/visualization/reporting. In order to help users identify where to go to ask questions of their data, a single Dashboards navigation option, available at the group and project levels is key. This feature is common with competitors and warrants a first class level navigation outside of any stage . </td> <td></td> <td></td> <td></td> <td></td> <td></td> </tr> <tr> <td> [Migrate existing "simple" Optimize dashboards to framework](https://gitlab.com/groups/gitlab-org/-/epics/15794) </td> <td>There are quite a few dashboards owned by the Optimize team that are deemed relatively straight-forward to migrate</td> <td></td> <td></td> <td></td> <td>In progress</td> <td></td> </tr> </table> ## Advanced | Feature | Reason | Priority | Status | |---------|--------|----------|--------| | Build new data exploration experience | Customers should be able to build custom dashboards from the UI by querying all supported data types. Currently the viz designer only allows users to query PA data, which is very limiting and creates a confusing experience when building custom dashboards. The goal will be to expand the viz designer to query Optimize metrics and event data. We would also iteratively expand to support querying other sources of GitLab data. | H | Planned for FY26Q4 | | CI/CD Analytics | Q3 POC to align pipeline tracing with existing monitor tracing data store and UI flows in order to accelerate their goal to provide critical pipeline analytics to GitLab users. In Q4 expand this capability to allow users to query this data and build their own team level dashboards with pipeline, o11y, VSA, and PA data. | | | | Decouple PA from Dashboard Framework | https://gitlab.com/groups/gitlab-org/-/epics/15691+: This work is needed in order to break the constructs that limit the ability for other teams to fully migrate to the dashboard framework. This includes removing the limitation for only querying product analytics data and also needing to enable the PA feature to see various features of the product. Additionally, this work opens up the feature beyond the Ultimate tier allowing use to migrate views that are available to premium customers as well. | H (critical to move forward) | In progress FY26 Q1 | | Remove the need for visualization files for every query | While the product was created with the idea that each visualization would be stored as a yaml file that created a library of possible charts for "easy" application when creating new dashboards, it is obvious that this flow will not scale. We are removing this requirement and reevaluating the workflow so that it will scale to accommodate the future where there could be thousands of queries run each data. | H | \| In progress FY25 Q4 \| | | Create subsections in dashboards with filter/time controls | Allow user to create blocks of viz/charts that have the same level of filter/time frame controls. This follows a similar model used by competitors where the dashboards either have tabs that act like separate dashboards, or they use sections within a single dashboard view to group data sources together that will be controlled by the same set of filters. | H | In design | | GLQL Investigation and early implementation | While GLQL is in its infancy in the Plan stage, we want to influence the direction so that it will become the SSoT for the method to query data in the dashboard data explorer. | H | In research | | Allow users to store the time frame with their query | Users may choose to store the exact time frame with the query they use to produce a visualization. This time frame should remain unaffected by any dashboard-level controls. Appropriate flag type messaging should let the users of that dashboard know that the data on that viz will not change when the time frame selector is modified. | H | In design and eng research phase | | Chart level error/notification messaging | Once the above options for chart or section level controls are added, the users of the dashboard (who may be different than the creator of the dashboard) will need hints as to why data does or doesn't change when dashboard level filters/time pickers are modified. They will also need to know that a change in those options generated a failure to return results. | H | | ### Open Questions | Question | Decision | |----------|----------| | Will users what to store configurations in multiple projects from one source project? Meaning if PMs want to store Product Analytics dashboard configs in a place separate from o11y dashboard configs, can we support config storage by dashboard? | Breaking this construct in FY25Q4, expanding this feature beyond the current PA restrictions and removing this config storage need. | | If a customer only uses one feature, aka one data source, do we want the FE to be smart enough to adjust to show only applicable filter/query options? | The UI will show the user what they have access to from all available supported data sources based on their tier and role. This will also be important at the dashboard level to ensure that users only have access to data they are allowed to see. Some of this will be in the form of user controls like the ability to set a dashboard as confidential, but others will be smart UI modifications based on tier/role access. | | | |