Critical Defect Tracking setup

Tracking your development team's “critical defects” opens the door to get an apples-to-apples comparison of how your team’s performance compares to other technology teams measured by Google in their Devops research:



The Google DORA metrics "Time to restore service" and "Change failure rate" both depend upon tracking critical defects.


Some examples of what you might consider a “Critical Defect”:

Bug that impairs payment

Bug that makes JavaScript unavailable for download

Bug that causes one or more customers to depart the product

User registration redirect without saving

Site load time now exceeding 1000ms per request

It is at the discretion of management how frequent a “critical defect” should be deemed to have occurred, but for the sake of team harmony, we strongly recommend consulting with your development team to settle on rules beforehand regarding what type of bugs will be designated as “critical.” This gives one's engineering leadership and developers a fair chance to build test coverage that reduces the likelihood of a critical defect occurring.


linkSetting up Critical Defect Tracking on GitClear

There are two options to designate when a Critical Defect has occurred:


linkVia a field and value in your issue tracker (e.g., Jira)

By default, if you are using Jira and you retain their default that offers a Highest value in the Priority column, then any newly filed issue that is marked as Highest priority will be considered a Critical Defect, so long as the issue is of type “Bug.”



Viewing the Critical Defect Fields for a project under "Settings" tab -> "Issue tracker projects"

You might have other fields in Jira that you use to indicate when a severe failure has occurred.You can choose any field from a Jira project, along with a value, by visiting your Issue Tracker Project settings. Here, you can click the "Add another defect mapping" link to get a list of Jira fields for the project:



The first step to adding a new critical defect detection field is choosing the field that will be scanned

After you have chosen which field should be inspected, you will need to choose the field value that indicates a critical defect. You can also use the checkbox to indicate whether the presence of the field/value pair you input should only count as a "critical defect" when the issue is of type "Bug":


After selecting which field to inspect, you can choose from a list of known values for the field, or you can enter your own string to check for

Putting it all together, if you click "Create new mapping" with these settings:


A new critical defect detection field/value pair being set up

Then your issue tracker project will reflect the newly created critical defect trigger:


After creating a new critical defect mapping

After creating this new defect detection field, issues of type "Bug" that have either the "Chargebacks" component OR are are marked "Highest" priority will be interpreted as critical defects. Following the creation of this new defect designation, GitClear will scan your issue tracker project to check for past critical defects, and backfill your historical stats so you can see how often critical defects have happened previously.


linkVia our restful API (beta)

GitClear is in the process of launching an API through which its customers can manually make a POST request when their systems indicate that a Critical Defect has occurred. Our API call has the advantage that it affords teams the opportunity to submit additional fields like “Severity.” This can be useful in high defect environments where a manager wants to sift out correlation in which teams are releasing the most debilitating bugs.


Please email support@gitclear.com if you would like access to our beta API. As of Q4 2021, this option is currently available only to paying Elite subscribers, but we are aiming to offer it to all paying customers (without emailing us) by the end of Q4 2021.