Accessing All Metrics
To view, click Eng Intelligence > All Metrics in the main nav:
Using All Metrics
The All Metrics view aggregates data from your connected entities to calculate critical metrics based on your organization’s priorities. The data is presented by team, group, or individual, and can be filtered by time range. Cortex provides a set of default metrics, but you can also create custom metrics to track here. These values are recalculated every hour. For count metrics (e.g., PRs opened) ,0 is displayed if no data is available. For average metrics (e.g., average PR open to close time), N/A is displayed if no data is available to calculate averages.
Apply time range and team filters
By default, All Metrics displays data from the last 7 days. To filter by time range:In the upper right corner of Eng Intelligence, click Last 7 days, then select a new time range for your metrics display:

-
Click Filter in the upper right corner.

- Click into Group, Owner, or Team, and select filter options.
- Click Apply.
Group by team hierarchy
By default, each Team entity in Cortex is displayed in its own dedicated row. To group by the team hierarchies you’ve created, click View as hierarchy.Group by entity type
By default, All Metrics displays Team data. In the upper left corner, click the Team dropdown to select a different entity type:
Group by user label
After you have set up user labels, you can group by labels. Click the Group by dropdown and select a label you want to group by. The grouping will be added as a row to the metrics table, along with separate rows for each member of the grouping.View more details for an entity
To better understand the data behind a trend you see, click an entity to open a side panel with more information:- Under the Related activity tab, see available metrics and recent activity.
- Under the Trends tab, see a historical performance graph for each metric.

Show Scorecard view
In the upper right corner, click Display. In this drop-down, you can choose whether to display entities in their associated hierarchies and you can select a Scorecard. When you select a Scorecard, Scorecard performance is overlayed in Eng Intelligence when grouped by team or service. This view is not available when grouping by group, user, or owner. The icon representing the Scorecard level achieved by each entity will appear next to the entity name:
Metrics
Users with theConfigure custom metrics permission can create custom metrics for All Metrics, or you can use the built-in metrics listed below.
These metrics are pulled from the Cortex deploys API, version control integrations (Azure DevOps, Bitbucket, GitHub, and GitLab), Jira, and PagerDuty.
Deploy metrics
Avg deploys/week
Avg deploys/week
Deploy change failure rate
Deploy change failure rate
Version control metrics
Avg PR open to close time
Avg PR open to close time
- Calculates the average time to close pull requests for each PR opened and merged during the selected time range.
- Pulls data from Azure DevOps, Bitbucket, GitHub, and GitLab.
Avg time to first review
Avg time to first review
- Determines average time from first open to first review of a pull request for any PR that has been opened during the selected time range.
- Pulls data from Azure DevOps, Bitbucket, GitHub, and GitLab.
Avg time to approval
Avg time to approval
- Displays average time from when a pull request was first opened to when it was first approved for any PR opened during the selected time range.
- Pulls data from Azure DevOps, Bitbucket, GitHub, and GitLab.
PRs opened
PRs opened
- Displays a count of pull requests opened during the selected time range.
- Pulls data from Azure DevOps, Bitbucket, GitHub, and GitLab.
Weekly PRs merged
Weekly PRs merged
- Calculates how many pull requests were opened each week, averaged across the weeks in the selected time range, to determine how many PRs were opened and merged each week.
- Pulls data from Azure DevOps, Bitbucket, GitHub, and GitLab.
Avg PRs reviewed/week
Avg PRs reviewed/week
- Calculates the number of pull requests that were reviewed each week, averaged across the selected time frame.
- Pulls data from Azure DevOps, Bitbucket, GitHub, and GitLab.
Avg commits per PR
Avg commits per PR
- Displays the number of commits required from PR open to close, and averaged across all PRs, for any PR opened and merged during the selected time range.
- Pulls data from Azure DevOps, GitHub, and GitLab.
Avg LOC changed per PR
Avg LOC changed per PR
- Displays the average number of lines added plus lines deleted for pull requests that were opened/merged during the selected timeframe.
- Pulls data from GitHub and GitLab. This metric is not supported for Azure DevOps.
Jira metrics
Issues completed
Issues completed
- Ticket 1: 1/5/2024, Entity 1
- Ticket 2: 12/1/2023, Entity 1
- Ticket 3: 1/15/2024, Entity 2
- Ticket 4: NULL, Entity 2
Entity 2 has 1 ticket completed during the timeframe (Ticket 3).
Story points completed
Story points completed
- Ticket 1: 1/5/2024, 3 points, Entity 1
- Ticket 2: 1/17/2024, null (0) points, Entity 1
- Ticket 3: 12/1/2023, 5 points, Entity 1
- This ticket does not fall within the selected time period.
- Ticket 4: 1/15/2024, 8 points, Entity 2
- Ticket 5: Null, 2 points, Entity 2
- This ticket does not fall within the selected time period.
Average days to complete
Average days to complete
- Ticket 1: 1/5/2024, 3 days, Entity 1
- Ticket 2: 1/10/2024, 5 days, Entity 1
- Ticket 3: 12/1/2023, 5 days, Entity 1
- Ticket 4, 1/15/2024, 8 days, Entity 2
- Ticket 5: Null, 2 days, Entity 2
Entity 2: 8 days / 1 = 8
% of sprint completed
% of sprint completed
- Sprint 1: 12/01/2023 to 12/15/2023 (not active)
- Sprint 2: 12/15/2023 to 1/1/2024 (active)
- Sprint 3: 1/1/2024 to 1/15/2024 (active)
- Sprint 4: 2/1/2024 to 2/15/2024 (active)
- Ticket 1: 12/14/2024, Sprint 1, Entity 1
- Excluded because of inactive sprint
- Ticket 2: 2/15/2023, Sprint 4, Entity 1
- Resolution date not within selected timeframe, but in active sprint. This counts toward the total number of tickets.
- Ticket 3: 1/14/2023, Sprint 3, Entity 1
- Resolution date is within selected timeframe and sprint is active. This counts as a resolved ticket and toward the total number of tickets.
- Ticket 4: 12/17/2023, Sprint 2, Entity 2
- Resolution date occurred before the timeframe, and in active sprint. This counts as a resolved ticket and toward the total number of tickets.
- Ticket 5: Null resolution date, Sprint 2, Entity 2
- Resolution date not within selected timeframe, but in active sprint. This counts toward the total number of tickets.
Entity 2: 1 resolved tickets / 2 total = 50%
Issues completed (custom grouping)
Issues completed (custom grouping)
Issue type: Bug and Component: Project A. The “Project A Bugs” grouping would become a column in the table, and Eng Intelligence will display the number of tickets closed for the selected time period matching the configuration of Issue type: Bug and Component: Project A.See Configure an issue grouping below for instructions on configuring groupings.CalculationAssume that you have selected a time period of 1/1/2024 - 2/1/2024.There are two groupings configured:- Grouping 1:
Label: EngineeringandIssue type: Bug. - Grouping 2:
Component: Backend
- Ticket 1: 1/5/2024,
Label: Engineering,Issue type: Story, Entity 1 - Ticket 2: 1/10/2024,
Label: Engineering,Issue type: Bug, Entity 1 - Ticket 3: 1/20/2023,
Component: Backend, Entity 1 - Ticket 4: 1/15/2024,
Component: Backend, Entity 2 - Ticket 5: NULL,
Label: Engineering,Issue type: Bug, Entity 2
- For Grouping 1, there was 1 ticket within the time period (Ticket 1).
- For Grouping 2, there was 1 ticket within the time period (Ticket 3).
- For Grouping 1, there were 0 tickets within the time period.
- For Grouping 2, there was 1 ticket within the time period (Ticket 4)
PagerDuty metrics
Mean time to resolve incidents
Mean time to resolve incidents
- Calculates average amount of time from incident open to resolution in the selected time range.
- Pulls data from PagerDuty.
Incidents opened
Incidents opened
- Displays sum of incidents opened for that time range; based on the most recently assigned user/team for each incident.
- Pulls data from PagerDuty.
Incidents opened/week
Incidents opened/week
- Displays sum of of incidents opened, divided by the number of weeks in the selected time range; based on the most recently assigned user/team for each incident.
- Pulls data from PagerDuty.
All Metrics settings
Change All Metrics appearance
From the All Metrics appearance settings, users with theConfigure Eng Intelligence permission can also choose which columns to display and adjust the order of columns in the All Metrics view.
Set filtering for metric calculation
From the All Metrics filters settings, users with theConfigure Eng Intelligence permission can set filters for some pre-defined metrics:
- Under Deploys, select the deploy environments you want to include in the calculation of deploy frequency and deploy failure rate. - If none are selected, all deploys will be included.
- Under Pull requests, select the authors you want to exclude from the calculation of PR-related metrics.
- If none are selected, PRs from all authors will be included.
- By default, Cortex filters out pull requests opened by bots in GitHub but does not do this automatically for GitLab.
Configuring Groupings for Jira Metrics
You can add custom groupings to Jira Issues based on labels, issue types, and components. The number of tickets completed for each grouping will be calculated in All Metrics using the custom name you configure for the grouping.- Navigate to the All Metrics settings page and click the Issue tracking tab.
-
On the right side of the page, click Add issue grouping.

-
In the modal, configure the issue grouping:
- Name: Enter a name for the grouping.
- Type: In the dropdown, select at least one issue type you want to track.
- Component: Enter the name of the Jira component you want to track.
- Label: Enter the name of the Jira label you want to track.
- Click Add issue grouping.
Create and manage user labels for grouping
User labels in Eng Intelligence allow you to group users into cohorts to analyze metrics based on different factors. This can be useful for benchmarking one engineer’s metrics against the average within a cohort, comparing metrics between engineers who use different tools to complete their work, and understanding metrics by different variables: location (e.g., in office or remote), engineer level (staff vs. lead engineer), tech stack (frontend vs. backend), and more. Users who have theConfigure user labels permission can create and apply labels.
The instructions below describe how to use this feature in the Cortex UI. See the Cortex API documentation for instructions on creating and managing user labels programmatically.
Create a user label
- In Cortex, navigate to the User labeling settings.
- Click your avatar in the lower left then click Settings.
- Under Eng Intelligence, click User labeling.
- In the upper right corner, click Create label.
- Fill out the “Create label” form:
- Name: Enter a descriptive name, e.g.,
Location. - Description: Optionally enter a description, such as “This label helps us understand metrics by location.”
- Values: Enter possible values for the label, e.g.,
New York,California,Remote.
- Name: Enter a descriptive name, e.g.,
- Click Create label.
- In Cortex, navigate to the User labeling settings.
-
In the list, locate the user you want to add a label to. Under the “Labels” column for that user, click the pencil icon.

- In the side panel, click into the dropdown to select a pre-existing label. To create a new label, type in a name then click +Create in the dropdown.
- At the bottom of the side panel, click Set labels.
- In Cortex, navigate to the User labeling settings.
-
Check the boxes next to the users you want to edit. As you check names, a banner will appear at the bottom of the page showing how many users are selected. In that banner, click Edit labels.

- In the bulk edit modal, enter the labels you want to add to the users, then click Set labels.