Skip to main content

Overview

DevEx Metrics helps you understand developer productivity at your organization. The plugin, displayed as a tab within the Insights plugin, automatically collects and ingests important data points covering the developer lifecycle (pull requests, CI/CD executions, incidents, and more) and aggregates them into metrics that are displayed in intuitive visualizations and dashboards. On the main page, you’ll get a snapshot of all metrics, grouped into categories like “DORA Metrics” and “AI Usage Metrics.” Each metric snapshot shows comparisons to previous periods as well as one or more supporting metrics for additional context.
DevEx Metrics overview page
Each metric can also be viewed in detail, where a timeseries or histogram view for the primary and supporting metrics are available.
DevEx Metrics detail page
Across all pages, you can filter to rolling date ranges (e.g. last month, last 3 months), or fixed date ranges (e.g. Q3, Q4, H2, etc). You can also filter by team, which is based on group ownership and membership within your Software Catalog.
Even though DevEx Metrics is shown within the Insights plugin, all data is stored within your Portal instance and is covered by all of the same data security and data privacy controls in place for the rest of the data available in your Portal instance.

Getting started

No action is necessary to get started! Core metrics that can be derived from systems for which you’ve already granted Portal access (e.g. SCM providers like GitHub, GitLab, or Azure DevOps) are available as soon as initial data loads are complete. Default metric calculations are based on input from developer productivity experts at Spotify and are designed to have the widest relevance within organizations.

Configuring sources

While many core metrics are automatically derived from data already available to Portal, you can unlock additional metrics by configuring credentials for relevant source systems. To add credentials for a source, click the ”?” icon to open the “Learn More” drawer for a given metric. There, you’ll see a list of Data Sources that can be used to power that metric, as well as a configuration status. Click the “Manage Integration” icon to add credentials in Portal’s integration settings.
Data sources pane

Supported sources

TypeSourceDetails
Source Code ManagementGitHubDeployment frequency, lead time for change, and supporting metrics can be tracked via repositories, pull requests, and workflow runs; these are automatically ingested based on credentials you’ve already configured in Portal. CI metrics derived from GitHub Actions are currently in beta.
GitLabDeployment frequency, lead time for change, and supporting metrics can be tracked via repositories, merge requests, and pipelines; these are automatically ingested based on credentials you’ve already configured in Portal.
Azure DevOpsDeployment frequency, lead time for change, and supporting metrics can be tracked via repositories, pull requests, and workflow runs; these are automatically ingested based on credentials you’ve already configured in Portal.
AIGitHub CopilotCopilot usage and billing data can be ingested to track key AI Usage metrics. Follow the guide above to configure this source.
CursorCursor data can be used to track key AI usage metrics. Grab an Admin API key and follow the guide above to configure this source.
ClaudeClaude data can be used to track key AI usage metrics. Grab anEnterprise Analytics API keywith the read:analytics scope and follow the guide above to configure this source.
Incident ManagementPagerDutyTime to Recovery and supporting metrics can be tracked via incidents and services; learn more aboutusing PagerDuty in Portal, then follow the guide above to configure this source.

Configuring metric calculations

Most metrics are built on common assumptions about how organizations use tools, however some metrics require additional configuration for accuracy. Like data sources, metric configurations can be configured from a metric’s “Learn More” drawer: in the section outlining how the metric is calculated, an “Edit” icon will appear. Clicking the icon will expose a form specific to the metric.
Metric configuration

Measurement strategies

Many metrics support custom measurement strategies. A measurement strategy controls the underlying data or methodology used to calculate a metric — for example, whether Deployment Frequency counts merged pull or merge requests or matched CI/CD runs. To choose a strategy, open the metric’s Learn More drawer and select Edit Calculation. The available strategies fall into a few common groups. Availability depends on the integrations configured for your organization; see the supported sources above for provider-specific details. Deployment Frequency strategies are configured separately for each SCM provider, so you can tailor what counts as a deployment to each provider’s tooling. Measurement strategy configuration for Deployment Frequency

Workflow filters

When you select a workflow-based measurement strategy for Deployment Frequency, you can add workflow filters to control which workflow runs are included in the metric calculation. Each filter can be set to include or exclude matching runs, and multiple filters can be combined. All text fields accept POSIX regular expressions, so a single filter can match an arbitrary number of workflows. Filters support multiple fields — for example, workflow name, branch, and conclusion — so you can express rules like “include all workflows whose name matches ^deploy-.* on the main branch” or “exclude all runs with a failure conclusion.” Workflow filters only apply when a workflow-based strategy is selected. Workflow filter configuration for Deployment Frequency

Metrics that require configuration

The following metrics require configuration for accuracy: AI Cost Per Engaged User While variable costs are calculated based on data provided by each vendor, this metric also requires fixed license costs for each vendor. Engineering Time Saved Time savings is calculated based on Software Template executions; a per-template time savings estimation is required to calculate total time savings.

Data segmentation

Segmentation lets you break down any metric by a property to understand what’s behind the numbers and where to focus. It is available on the dashboard view of every metric group. You can segment by two properties:

Team

Breaks down metric values by the teams defined in your Software Catalog. Use this to compare how different teams contribute to an overall metric and identify where to focus improvement efforts. Teams are resolved from ownership relationships in your catalog entities. If an entity belongs to multiple teams, its contribution is reflected in each relevant segment.

Soundcheck track

Breaks down metric values by your Soundcheck tracks — the standards your organization has defined for software health and compliance. Use this to view your DevEx data from the perspective of standards adoption and understand how entities that meet or don’t meet specific tracks contribute to your metrics.
Values are weighted proportionally based on how each data source’s entities are distributed across segments. Totals across segments may not match the unsegmented value because each data source’s contribution is split across the relevant segments. Use the diagnose panel to see exactly how attribution is calculated for your current view.

Diagnose

The diagnose panel helps you understand the results shown in your dashboard, especially when filters or segmentation produce unexpected numbers or gaps in data. It is available on every metric group alongside the segment controls. The panel surfaces four categories of information:

Example findings

No data imported yet — A configured data source has not completed its first import. Check that the integration is set up and the data import has run at least once. No segments have data — None of the entities matched any segments in the selected time range. Verify that your catalog entities have the expected team ownership or Soundcheck track associations.

Frequently asked questions

How does date filtering work?

DevEx Metrics allows you to set and compare dates in either rolling windows (e.g. the most recent 1, 3, or 6 months) for staying on top of recent trends, as well as fixed windows (e.g. quarters or halves) for big-picture reflection. In order to always show you complete, accurate data, the plugin aligns date windows to ISO weeks (Monday-to-Monday) when viewing data at a weekly granularity. At a monthly granularity, dates will be aligned to ISO months, except for the last month which ends before the last Monday.

How does team filtering work?

In both the overview and metric detail views, you’re able to filter down to specific teams. These teams are groups represented in the Software Catalog. If your catalog represents group hierarchy accurately, selecting a higher-level group (e.g. a product area, department, or business unit) will effectively show metrics for all child ancestors that belong to the selected group. How each metric is filtered depends on the underlying data behind the metric, as well as the accuracy of metadata and relationships within the Catalog. Use the following table as a guide when troubleshooting team-based filtering of metrics.

Why do segment totals not match the unsegmented value?

Values are weighted proportionally based on how each data source’s entities are distributed across segments. Because each data source’s contribution is split, the sum of segments may differ from the overall total. Open the diagnose panel to see how attribution is calculated for your current view.

Why do I see “No segments have data”?

This means none of your entities matched any segments in the selected time period. Check that your catalog entities have the correct team ownership or Soundcheck track associations for the segmentation property you selected.