DORA Metrics Dashboard

Hatica DORA dashboard

This dashboard provides valuable insights into the performance and efficiency of software development and delivery processes for a selected team along with the ability to drill down to a service and individual level.

Data Sources:

VCS Tools
Incident Management Tools
Project Management Tools - Jira
CI/CD Tools

Available filters

Date Range Picker
Services
Individuals
Repos

Walkthrough

This dashboard builds on the information you see on the Services overview dashboard. With the added functionality to drill down and analyze all four metrics for the selected team. To reiterate, the four metrics are:

Deployment Frequency: Deployment Frequency is the ratio of total production deployments completed to the number of days in the selected date range. You can read more about the metric and industry benchmarks here (opens in a new tab).
Change Failure Rate: Change Failure Rate is the percentage of deployments that cause a failure in production. Note that this is not a measure of deployments failures, but changes that cause the application to fail. You can read more about the metric and industry benchmarks here (opens in a new tab).
Cycle Time: Cycle Time refers to the time it takes from the first code commit to production deployment. You can read more about the metric and industry benchmarks here (opens in a new tab).
Mean Time to Restore: Mean time to restore (MTTR) is a metric that measures how long it takes to recover from a production incident or outage. You can read more about the metric and industry benchmarks here (opens in a new tab).

Upon clicking on each of the 4 metrics' tabs, you can also see a histogram for the metric spread across the date range selected. You also get a table view of all the deployments/incidents/PRs that align with the filters selected.

Hatica DORA table view

How to use the DORA dashboard:

Measure CI/CD & Release Effectiveness: DORA metrics help assess how effectively development and operations teams are working together. By tracking these metrics, organizations can identify strengths and areas for improvement in their DevOps practices.
Understand Deployment Frequency: Deployment Frequency indicate how often code changes are delivered to production. Regular and efficient deployments are linked to faster feature delivery and improved responsiveness to market needs.
Improve Total Cycle Time: Total Cycle Time refers to the time it takes from code commit to production deployment. Shorter lead times generally mean faster delivery of new features and bug fixes, leading to better user satisfaction and competitive advantage.
Reduce Change Failure Rate: By monitoring how often deployments result in failures or require fixes, organizations can work on improving code quality and testing processes. Lower change failure rates contribute to more stable and reliable software. CFR up to 15% is acceptable; if it's lower then the team can probably move faster. On the other hand, if it's higher then the team should move slower and focus on quality of what they're releasing.
Minimise Time to Restore Service: Faster recovery times reduce downtime and improve the overall reliability and resilience of services.
Drive Continuous Improvement: DORA metrics provide data-driven insights that help teams continuously refine their processes, adopt best practices, and achieve higher levels of performance and quality.

By focusing on metrics that impact deployment speed, stability, and efficiency, team leads/managers can align their technical practices with broader business objectives such as faster time-to-market and customer satisfaction.

NOTE

The Hatica SLA for data sync is 48 hours for the repositories on an incremental basis.
Initial sync can take up to 3 days, and does not have an SLA as it is dependent on the number and size of repositories and varies with each organization.
This does not restrict you from sending deployment data via any of the supported deployment tracking mechanisms including API.
However, if the repository is not synced then the PR that is being marked as deployed marked as deployed probably doesn't yet exist in Hatica.
When the Repository sync completes, the PR will be available in Hatica. Post that, Hatica reprocesses the Deployment data and marks the PR as deployed.
Once the PR is marked as deployed it will appear in the DORA dashboard.
The team/individual filter relies on the PR being marked as deployed.