DORA Metrics in Kindor

If you’ve already read our intro to DORA metrics, you know they’re a powerful way to measure software delivery performance. But knowing what to measure is just the first step, what matters most is how you use those metrics to drive improvement.

In this post, we’ll walk you through how Kindor helps you consume DORA metrics in a way that’s automated, contextualized, and actually useful. You’ll learn how Kindor captures each metric from your existing tools and how it can be adapted to your unique way of work.

Where to find them

DORA Metrics are typically measured at the team level, which is why you’ll find them in the Teams section within Kindor.

When you open the Teams Overview Dashboard, you’ll first see a set of high-level KPIs. These often include metrics aligned with the DORA framework, such as number of deployments, PR cycle time, and number of incidents. All automatically calculated based on the selected team and time period (e.g. “last 30 days” or a specific sprint range).

For a deeper dive, you can click the “View More” option below each KPI. This takes you to a more detailed dashboard that displays the metric over time and lets you filter across multiple time ranges.

For instance, clicking “View More” under the “Number of Deployments” KPI will take you to the Delivery dashboard. There, you’ll find additional metrics such as PRs created and merged, tasks and story points completed, deployment frequency, and cycle times for tasks and PRs, all of which can be filtered by team and time period.

For quality-related metrics such as Change Failure Rate and Mean Time to Restore, you can head to the Quality dashboard, also within the Teams section.

This dashboard displays KPIs and timeline trends showing the number of bugs reported and resolved, broken down by team, project, and selected time range. You can also filter by bug type based on the categories your organization uses.

In addition, you’ll find key reliability metrics like Change Failure Rate, Total Number of Incidents, Mean Time to Acknowledge, and Mean Time to Restore, all helping you assess how quickly and effectively your team responds to failures.

If you want to explore the data in more detail, you can navigate to other sections of the product.

For example, to understand how PR cycle times are composed, go to the Repositories section. This view provides detailed insights for each repository in your organization, helping you quickly identify those with fewer deployments, longer cycle times, or lower code review activity.

By selecting a specific repository, you’ll access a breakdown of the PR cycle time, including coding time, pickup time, and review time, along with a view of how these times are distributed over the selected period.

For quality metrics, go to the Projects section. This area gives you a detailed view of each project in your organization, showing the number of bugs handled per team and project.

By selecting a specific project, you can access its detailed view. There, you’ll be able to filter by issue or task type and review key information such as cycle times, number of bugs, and the team members involved in resolving them.

How DORA Metrics are configured in Kindor

Every organization has its own development and deployment workflows, so Kindor was designed with flexibility in mind. All DORA metrics in Kindor are fully customizable to fit your specific processes.

Deployment Frequency

By default, Kindor considers every pull request merged into the default branch of a repository as a deployment. For example, if your default branch is master, any pull request that reaches this branch will count as a deployment.

However, you can configure this behavior in several ways:

• Specific branch for deployments: If your team uses a dedicated branch for production deployments, such as prod, Kindor can be set up to count merges into that branch as deployments instead.

• Jira Releases: If your organization uses the Jira Releases feature, Kindor can read this data to calculate deployment events at the organization, team, and project level.

• Specific Task Type: If you track deployments through a specific task type in your project management tool, Kindor can be configured to treat the completion of these tasks as deployment events, using the task’s completion date.

  
  

Cycle Times

Kindor provides a detailed breakdown of pull request cycle times to help you identify delays and optimize delivery as follows:

• Lead Time: Time between the moment a related task is first moved to an “In Progress” status and the moment the pull request is merged.

• Cycle Time: Time from the first commit in the pull request to when it is merged.

• Coding Time: Time from the first commit to the creation of the pull request.

• Pickup Time: Time from when the pull request is created to when the first comment is made.

• Review Time: Time from the first comment on the pull request to when it is merged.

Change Failure Rate (CFR) and Mean Time to Restore (MTTR)

Kindor calculates Change Failure Rate and Mean Time to Restore using data from your project management system.

By default, Kindor treats as incidents any task of type bug or a related type (such as defect, incident, error, etc.) that is marked with a high priority (could also be “Highest,” “Critical,” , “P1”, etc).

However, this behavior can be customized in several ways:

• Specific project: If your organization uses a dedicated project for incident management, Kindor can be configured to consider every task in that project as an incident.

• Specific label: If you tag incidents using a specific label, Kindor can be set to identify any task with that label as an incident.

• Specific task type: If you track incidents using a custom task type like “Incident,” Kindor can be configured to treat all tasks of that type as incidents.

Once an incident is identified, Kindor measures its cycle time to calculate Mean Time to Restore.

For Time to Acknowledge, Kindor measures the time between the task’s creation and the moment it is moved to an “In Progress” status.

Going Beyond Static Dashboards

In addition to tracking DORA metrics through Kindor’s dashboards, users can take a more proactive approach by enabling Kindor notifications, designed to support continuous improvement.

Through the Kindor Advisor module, you can activate smart notifications such as:

• Pull requests open for too long

• Low deployment frequency

• High change lead time

Each of these alerts comes with configurable thresholds, allowing you to tailor them to your team’s context and goals.

You can also enable complementary notifications that indirectly support improvements in DORA metrics. Examples include:

• Pull requests with a high number of code additions

• Tasks that have remained in progress for an extended period

  
  

These insights help teams identify blockers and inefficiencies early, encouraging faster, more reliable delivery.