📖
Typo Help Docs
  • Welcome
  • Getting Started
    • Onboarding
    • Integrations
      • Git
        • GitHub
        • GitLab
        • BitBucket
        • Azure Repos
        • Gitlab On-prem
      • Issue Tracker
        • JIRA
        • Linear
        • GitHub Issue
        • Shortcut
        • ClickUp
      • CI/CD Tool
        • Circle CI
        • Jenkins
        • Heroku
        • GitHub Actions
        • Azure DevOps
        • Custom Deployment Webhook
      • Slack
    • How Requestly setup Typo in a few days
  • Platform
    • Dev Analytics
      • DORA
      • Insights
        • Teams
        • Members
        • Sprints
        • Pull Requests
        • Deployments
      • Incident
      • Goals
      • Investment
      • Initiative
      • WorkLog
      • Custom Reports
      • Settings
        • Teams
        • Member
        • Repository
        • Projects
        • Manage Access
        • Notifications
    • Code Health
      • Code Review
      • Code Coverage
    • DevEx
  • Implementation Plan
    • Phase 1 - Setting Up Data Sources
    • Phase 2 - Metric Configuration
      • Dev360
      • Code Health
      • DevEx
    • Phase 3 - Team Rollout
  • Engineering Metrics
    • DORA
      • Cycle Time
      • Deployment PRs
      • Change Failure Rate
      • Mean Time to Restore
    • Pull Request Metrics
      • Avg. Commits During PR Review
      • Coding Days
      • Coding Time
      • Merge frequency
      • Merge Time
      • Pickup Time
      • PR Size
      • PRs Merged without Review
      • Review Time
      • Efficiency Score
    • Sprint Metrics
      • Carry over
      • Developer Workload
      • Issue Cycle Time
      • Issues At-Risk
      • Scope creep
      • Team Velocity
      • Work Breakup
      • Work Progress
    • Code Quality Metrics
      • OWASP Top 10
      • Vulnerability
      • Security
      • Performance
      • Duplication
      • Code Smell
    • Deployment Metrics
      • Deployment - Failure
      • Deployment - Frequency
      • Time to Build
    • Incident Metrics
      • Incident - Opened
      • Avg Resolution Time
    • DevEx Metrics
      • DevEx Score
      • Space mood
      • Response Rate
      • Manager Support
      • Developer Flow
      • Product Management
      • Development & Releases
      • Culture & Values
  • Configurations
    • Cycle Time
    • Deployment PRs
    • Change Failure Rate (CFR)
    • Mean Time To Restore (MTTR)
    • CI/CD - Deployment
    • Incident
    • Initiative
    • Investment Distribution
    • PR Labels
    • Code Health
    • Code Coverage
    • DevEx
    • Notifications
    • Manage Access
  • FAQ's
    • Data Security
      • GitHub App Permissions Details
      • Why does Typo need write permission to my code?
      • Does Typo has access to my code?
      • What data security guidelines does Typo follow?
    • Integrations
      • Can Typo application work with on-prem Gitlab?
      • How do I get Issue Tracker data?
      • How do I get Git data?
    • Pricing
      • How does the pricing work?
      • How do I upgrade my plan?
    • Access Management
      • My team member is not able to login to Typo
    • Metrics
      • How does Typo predict developer burnout?
      • Is there a way to change the branch that Deployment PRs are measured against?
      • Synchronize “CFR” & “MTTR” without incident management?
      • How quick does the pull-request page update? I closed a PR but the Typo still shows Awaiting Review
      • How do I add any new repo?
      • How to Configure Typo Code Health Checks to Block a PR Merge in Git
      • Can I exclude a person from metrics calculation?
      • Can I track the Cycle time based on the status of the JIRA tickets?
      • How do I unlink the JIRA tracker & integrate Linear?
      • How to exclude a PR from any metric calculation?
      • My data is not visible, I have synced the repo
    • Platform
      • Can I use your application on-premise?
    • Delete Account
      • How can I delete my account?
Powered by GitBook
On this page
  1. Engineering Metrics
  2. DORA

Change Failure Rate

PreviousDeployment PRsNextMean Time to Restore

Last updated 9 months ago

CFR(Change Failure Rate) refers to the proportion or percentage of deployments that result in failure or errors, indicating the rate at which changes negatively impact the stability or functionality of the system.

Since the definition of Failure is specific to teams, there are multiple ways this metric can be configured. Here are some guidelines on what can indicate a failure :

  • A deployment that needs a rollback or a hotfix For such cases, any Pull Request having a title/tag/label that represents a rollback/hotfix that is merged to production can be considered a failure

  • A high-priority production incident For such cases, any ticket in your Issue Tracker having a title/tag/label that represents a high-priority production incident can be considered a failure

  • A deployment that failed during the production workflow For such cases, Typo can integrate with your CI/CD tool and consider any failed deployment as a failure

To calculate the final percentage, the total number of failures is divided by the total number of deployments (this can be picked either from the Deployment PRs or from the CI/CD tool deployments).

💡 Here is an important tip on how you can use CFR on the Typo dashboard

Benchmarking CFR will help you evaluate performance and establish a baseline for acceptable change failure rates, enabling you to set targets for reducing failures and enhancing the overall quality.

You can click on the “>” arrow to see all the deployments.

How does measuring CFR help in improving the Engineering teams' efficiency?

Measuring change failure rate provides critical insights into the stability and reliability of an engineering team's development and deployment processes. This metric can help identify potential risks, assess the effectiveness of quality control measures, and guide improvements to enhance team efficiency. Here are some specific insights that can be gained from measuring change failure rate and how they can be used to improve engineering team efficiency:

  1. Release Quality: A high change failure rate suggests that there may be issues with the development and testing processes that need to be addressed.

  2. Testing Effectiveness: A high change failure rate may indicate gaps or weaknesses in the testing process. Measuring this metric helps in evaluating the effectiveness of automated and manual testing efforts.

  3. Root Cause Analysis: Change failure rate can serve as a starting point for conducting root cause analysis of failures in the production environment.

  4. Continuous Improvement: Tracking the change failure rate over time allows the team to monitor the impact of process changes and improvements.

Click here to learn more about

CFR(Change Failure Rate) configuration