"Critical Defects" are the label that GitClear uses to refer to bugs or defects that are severe enough that the team is expected to fix them urgently (in the earliest possible release).

Some terms our customers use that map to what GitClear calls "Critical Defects":

When you instrument your team's Critical Defects, you open access to a myriad of DORA-based metrics. What makes the DORA metrics interesting is that they have been widely measured across the software industry, so it's easy to see how your team's "release velocity" and "bug prevalence" compare to industry norms. You can learn more about how those industry norms are calculated in Google's annual DORA report (distilled summary), which has been conducting industry surveys for more than 10 years.

On this page, we'll provide all the details you need to fine-tune how you capture when a "Critical Defect" has occurred.

We strongly recommend that every new GitClear customer spends at least 10 minutes to think about how their team processes an incoming "urgent bugfix." As long as you have a consistent process for it, GitClear will help you record your historical performance in minimizing these incidents: both in absolute number, and in "time until the fix is released."

Topics covered on this page:

For more specific implementation details of how Critical Defects become Google DORA stats, see our help page on DORA Units & Definitions.

linkHow Critical Defects Relate to DORA Stats

open_in_new

Critical defects underlie the "Change fail rate" and "Failed deployment recovery" metrics

Two of the four "classic" Google DORA metrics are relate to Critical Defects.

Setting up Critical Defects unlocks access to a plethora of charts and notifications: segmented by repo (or "microservice"), team, and time.

linkAutomatic Defect Detection 🪄

Upon signing up for GitClear, we give you a head start on configuring your "critical defect measurement" by automatically applying two rules (either of which can be disabled in the "Settings" tab).

link1. Mention of "hotfix" in branch, PR title, or issue title

Any time that the word "hotfix" (case-insensitive) is used in a git branch (during the time GitClear is processing that branch), a pull request title, or an issue title, a critical defect will be created with details of the source where the term was found.

If the "hotfix" term is used on a single issue that spans a branch, pull request, and issue, don't worry - we will only create one critical defect. The precedence for "defect term" source is branch < PR < issue.

link2. "Severity" or "Priority" Issue Field in Jira

When you connect with Jira, GitClear will automatically check if your projects contain a "Severity" or "Priority" field (most all do). When a new issue is created with the label of highest, critical, or major, a critical defect will be created. If you'd like to have different labels translate to a critical defect, read on -- the "Setting up Critical Defects" section describes this.

linkSetting up Critical Defect Tracking on GitClear

GitClear offers three options to expand upon the defaults, to ensure you record instances of any Critical Defects that define several of the DORA stats.

link📝 By looking for mention of words like "hotfix"

If there is a term like hotfix that consistency occurs when an urgent bug is discovered, GitClear can key off that "Defect Detection Term" to create Critical Defects. Any Defect Detection Term you create will be matched when present in a 1) git branch name 2) pull request title or 3) issue title.

To add Defect Detection Terms beyond "hotfix" (added by default), visit the "Settings" tab of your entity/organization/repo, and choose "Critical Defect detection terms" from the menu on the left.

link🐞 Via a field and value in your issue tracker

After connecting your issue tracker, we'll automatically check for a Priority column with the value Highest, which will be considered a Critical Defect, so long as the issue is of type “Bug.”

open_in_new

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:

open_in_new

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":

open_in_new

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:

open_in_new

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

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

open_in_new

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.

link🤓 Via our Restful API

Our API makes it easy to create and resolve Critical Defects. Learn more about the Critical Defect endpoint here.