Repository-Level Metrics

Repository-level metrics allow you to monitor and compare the performance of individual repositories in LinearB. Available in paid plans, these views help you analyze code health, development trends, and quality indicators across any connected repo.

Accessing Repository Metrics

To view metrics for a specific repository:

1. Go to the Metrics tab and click the + icon.
2. Open any pre-built report.
3. Change the Filter by option from People to Repository.
4. LinearB will remember your selected repository or team the next time you return.

Custom dashboards can also be configured to permanently display data for a selected repository.

Creating a Repository-Specific Dashboard

To build a dashboard focused on a single repo:

1. Click the plus (+) icon in the top-left corner of the Metrics page.
2. Name your new dashboard.
3. Select the required repository using the Repository filter.
4. Click + Add metrics to choose the metrics you want to track.
5. Click Save.

Once you’ve created a dashboard, you can duplicate it to quickly build similar dashboards for other repositories—just update the repository selection and save again.

Use Cases for Repository Metrics

There are many benefits to having repo-level metrics available.

Comparing Repository Performance

Create multiple dashboards using the same metric set and assign each one to a different repository. This allows you to compare quality, efficiency, and delivery trends side by side.

Identifying Repositories That Require Attention

Build a quality-focused dashboard for a specific repository. Use it to detect signs of inefficiency, maintainability concerns, or code complexity. Consider tracking the following metrics:

• PR Size – A growing trend in PR size may indicate the repo is becoming difficult to manage. Encourage smaller, more focused branches.
• Rework – Frequent rework shortly after merging may signal poor code quality or lack of testing.
• Refactor – A spike in refactoring activity may suggest the repo is aging poorly or not integrating well with other services.
• Review Depth – Deeper or prolonged review cycles may highlight challenges in code clarity or structure.
• Coding Time – Longer coding durations might indicate the codebase is difficult to navigate, update, or understand.

These metrics help surface friction points, inform architectural reviews, and support continuous improvement for each service or module.