Using Port Insights to measure DORA metrics

Earlier this year, we introduced Insights—a feature designed to provide engineering leaders with all the metrics they need to manage their teams and operations efficiently.

Our vision for Insights was to leverage the data you already have in Port to give you a clear view of your team's performance. We wanted to "turn the light on" so you can easily answer critical questions like:

• How are my teams doing?
• Which team is struggling to resolve incidents?
• How does this month's deployment frequency compare to last month's?

{{cta-demo}}

But with so many metrics available, it's easy to get lost in the data. From pull request statistics and bug counts to planning forecasts and quality indicators—the depth and breadth can be overwhelming. This leads to a question: Where should you start?

Enter the DORA framework

Researchers at Google introduced the DORA (DevOps Research and Assessment) framework to evaluate the performance of engineering teams. It zeroes in on four key metrics:

• Deployment Frequency
• Lead Time for Changes
• Change Failure Rate
• Mean Time to Recovery (MTTR)

Why these metrics? The goal was to measure not just the performance of an engineering organization but also the stability of its software. After all, what's the point of moving fast if the software isn't reliable? 

The DORA framework ensures you're balancing speed with stability, so you're not just accelerating—you're doing so responsibly.

Starting with DORA provides a solid foundation. If you're new to tracking engineering metrics, we highly recommend beginning here. These four metrics offer a clear, focused view of your team's performance, helping you identify areas that need attention.

But while DORA metrics offer a solid starting point, collecting and interpreting them isn't always straightforward.

The challenge of tracking DORA metrics

Once you've begun delving deeper into DORA, you'll find that gathering and interpreting the data can be more complex than it initially appears. The data often needs to be pulled from various sources—Git providers, CI/CD pipelines, incident management tools—which might seem straightforward but can quickly become complicated.

Defining your metrics

The first hurdle is understanding how you want to measure each metric. Take Deployment Frequency as an example:

• What counts as a deployment? Is it a merge to the main branch? A triggered pipeline that deploys code to production? Or simply a commit to the main branch? 
• Team-specific measurements: If you're assessing deployment frequency per team, do you count deployments of services that a specific team owns? Or do you consider every commit made by team members, regardless of the service?

These questions highlight how significantly definitions can vary based on your tech stack and organizational practices. Without clear definitions, the metrics you gather may not accurately reflect your team's performance.

What’s next?

After establishing a baseline with DORA, you can begin to explore additional metrics that provide more granular insights. For instance, if you're looking to further improve your deployment frequency, consider examining:

• Time from first commit to pull request created
• Time to review
• Time to merge
• Build duration
• Build success rate
• Time to deploy
• Number of open pull requests
• Number of merged pull requests
• And so on…

Understanding the context is just as important as the metrics themselves. For example, you might observe a decrease in deployment frequency alongside an increase in the number of incidents. This pattern could indicate that teams are deploying less frequently due to stability issues.

Turning metrics into action

Once you've gathered your metrics and set your benchmarks—whether using the DORA benchmarks or your own—the next step is to put this information to practical use.

• Benchmark and assess: Begin by evaluating each team's performance against your chosen benchmarks.

• Set up alerts: Consider setting up alerts for managers when their teams fall below certain thresholds. 
• Collaborate with your platform engineering team: Work closely with your platform engineering team to develop solutions to the challenges you've identified. For example:some text
  • Long lead times: If code reviews are taking too long, implement an automation that nudges reviewers after a specific period.
  • High MTTR: If your mean time to recovery is higher than you'd like, centralizing all incident data in one place can streamline resolution efforts and reduce recovery times.

Using a developer portal to track DORA metrics and more

A developer portal like Port can be a significant asset in this process:

• Unopinionated data model: Unlike other tools, Port isn't opinionated about how you define your metrics. It lets you specify what constitutes a deployment, lead time, or incident based on your organization's unique terminology and practices. You gather data from the tools you already use and analyze it in ways that align with your specific needs.
• Seamless integration: Because Port connects directly with your tech stack, diving deeper into your metrics is straightforward. You can easily add more information as your needs evolve.
• Comprehensive context: Having all your data connected means you get the full picture—not just isolated metrics, but the context that gives them meaning.
• From data to improvement: Port isn't just for tracking metrics; it's also a platform for implementing solutions. With features like scorecards, automations, and alerts, you can actively work to improve your metrics, not just monitor them

Ready to take the next step?

Follow our guide to start tracking DORA metrics now and see how you can start impacting your engineering performance.