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.
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 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.
Supported sources
| Type | Source | Details |
|---|---|---|
| Source Code Management | GitHub | Deployment 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. |
| Azure DevOps | Deployment 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. | |
| AI | GitHub Copilot | Copilot usage and billing data can be ingested to track key AI Usage metrics. Follow the guide above to configure this source. |
| Cursor | Cursor data can be used to track key AI usage metrics. Grab an Admin API key and follow the guide above to configure this source. | |
| Claude | Claude 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 Management | PagerDuty | Time 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.
Measurement strategies
Some metrics support multiple measurement strategies. A measurement strategy controls the underlying methodology used to calculate a metric — for example, which events or signals are counted. When more than one strategy is available, you can switch between them by going to the metric’s “Learn More” drawer > Edit Calculation to find the approach that best matches how your organization works. Strategies are configured separately for each SCM provider (e.g. GitHub and Azure DevOps), so you can tailor the calculation to each provider’s tooling. Measurement strategies are currently available for Deployment Frequency. Use them to define what counts as a “deployment” for your organization — whether that’s all pull requests merged to the main branch, matched CI/CD workflow runs, or neither.
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.
