Advanced Settings for Clean Data

Using Advanced Settings to Clean up your Data

Video Walkthrough: Advanced Company Settings in LinearB

---

Configure Release Detection (4 Supported Methods)

Why
Releases define Deployment Frequency, Lead Time, and accurate cycle-time closure.

What metrics are affected by this configuration?

• Deployment time (Cycle time) - this is how LinearB will know when to identify + start tracking a deployment
• Deployment frequency - LinearB will need to know how to identify you deployments to calculate frequency.
• CFR -  LinearB will need to know how to identify your deployments to associate failure incidents with releases

LinearB supports four release triggers:

Method A — Release by Tag (default)

• Most popular option if you tag your releases.
• Triggered when a Git push occurs to a tagged commit.
• Every commit appearing in the tagged branch is considered released.
• Supports regular expression (regex) to filter tag names by prefix/suffix.

Method B — Release by PR to a Dedicated Branch

Note: This method will cause Deploy Time to register as 0 (deploy time measured from PR approval to deploy is effectively skipped).

• LinearB listens for PRs merged into dedicated branch(es) to define a release.
• Any PR merged to a release branch (e.g. main) is treated as a deploy.
• Set which branch(es) LinearB should listen to using a regex expression.
• Default expression: ^(main|master|production|prod)$

Method C — Release by Direct Merge to a Branch

• Used when your org merges directly into a dedicated release branch without using PRs.
• LinearB detects the merged commit and marks included branches as deployed at time of merge.
• Set which branch(es) to listen to by regex.
• Default expression: ^(main|master|production|prod)$

Method D — Release by Deployment API

• Report deployments and release events from your CI/CD system.
• Best for teams relying on CI/CD for release management and seeking deployment metric accuracy.
• Supports multi-stage release detection with LinearB’s custom stages.
• Deployments are matched to merged branches using Git ancestry (i.e. is this branch’s commit an ancestor of the deployed commit?).

Note: Please follow this link to learn more details about our Deployment API

Where to Configure Release Detection

Org-wide Release Detection

Set the organization-wide release detection method

1. In LinearB, go to Company Settings → Advanced.
2. In the Release Detection section, select your desired release detection method.
3. Click Save to apply your changes.

Override release detection per repo
Why
Individual repos can use a different release detection method than the organization default. For example, the org may use tag-based releases, while a specific team uses the Deployment API.

1. In LinearB, Go to Company Settings → Git.
2. Click the gear icon to the right of the repo you'd like to set specific release detection rules for.
3. In the Release Detection section, select the desired release detection method for this team.
4. Click Save to apply your changes.

---

Branch Exclusions

Why
Exclude test or non-production branches that shouldn’t count toward metrics to improve data accuracy.

What metrics are affected by this configuration?

• All metrics with some exceptions (e.g. MTTR)

Defaults

^develop$
^development$
^master$
^staging$
^integration$
^release$
^production$
^main$

Custom Examples

test/*
demo/*
sandbox/*

Where to configure

Org-Wide Branch Exclusion

Set the organization-wide branch exclusion configuration

1. In LinearB, go to Company Settings → Advanced.
2. Scroll to the Exclude Branches section.
3. Add one regular expression per line to describe the branch patterns you want LinearB to ignore.

Branch Exclusion per Repo

Override branch exclusion configuration per repo
Why
Individual teams can use a different branch exclusion configuration than the organization default.

1. Go to Settings → Git.
2. Select the gear icon to the right of the repo you'd like to configure differently.
3. In the Exclude Branches section, add one regular expression per line to describe the branch patterns to ignore for this repo.

---

File Exclusions

Why
Prevents non-code files from affecting PR size, new code %, and overall accuracy.

What metrics are affected by this configuration?

• PR size - excluding a file(s) will decrease PR size

Defaults

.*package-lock\.json$
.*dist/.*\.js
.*public/assets/.*\.js
.*\.(ini|csv|xlsx|txt|doc|rtf|ipynb|resx)$

Where to configure

Set the organization-wide file exclusion configuration

1. In LinearB, go to Company Settings → Advanced.
2. In the Exclude File Extensions section, add one regular expression per line to describe the file patterns LinearB should ignore.

Override file exclusion configuration per repo
Why
Individual teams can use a different file exclusion configuration than the organization default.

1. Go to Settings → Git.
2. Select the gear icon to the right of the repo you'd like to configure differently.
3. In the Exclude File Extensions section, add one regular expression per line to describe the file patterns to ignore for this repo.

---

Draft Pull Requests

Why
Draft Pull Requests ensure that early or incomplete work does not distort Cycle Time, Pickup Time, or Review Time. LinearB automatically excludes draft PRs from key metrics until they are ready for review, giving you a cleaner and more accurate view of delivery performance.

What metrics are affected by this configuration?

• Coding time - attribute time that it is draft to coding time
• labels the PR - "draft"

How LinearB identifies draft PRs

LinearB can treat a pull request as draft when it matches either (or both) of the following:

• Has one of your configured labels for draft work.
• Has a title that matches a regular expression pattern you define.

Where to configure Draft Pull Requests

Set the organization-wide draft pull request configuration

1. In LinearB, go to Company Settings → Advanced.
2. Scroll to the Draft Pull Requests section.

Override draft pull request configuration per repo
Why
Individual teams can use a different draft PR configuration than the organization default.

1. Go to Settings → Git.
2. Select the gear icon to the right of the repo you'd like to configure differently.
3. Open the Draft Pull Requests section.

Steps — Configure labels and title pattern

1. In the Draft Pull Requests section, add the labels your organization uses for draft work. For example:

   • wip
   • do_not_merge
   • work in progress
   • work_in_progress

   Any PR with one of these labels will be treated as a draft.

2. Optionally, specify a regular expression for PR titles that should be treated as draft. A common example is:
   ^.*wip.*$
3. Click Save to apply your changes.

Note: Changes to draft PR settings are applied from the time of the saved configuration, moving forward.

Best practices

• Standardize on one or two labels (for example, wip and do_not_merge) across all teams.
• Use labels for clarity, and the title pattern as a safety net for ad-hoc “WIP” titles.
• Review your existing PR conventions before changing these settings, so historical behavior remains intuitive for developers.

---

Exclude Bots

Why
Bot commits can inflate activity and PR metrics if not excluded.

What metrics are affected by this configuration?

• Cycle time metrics - not excluding bots may create an inaccurate cycle time calculation.

How:

1. Locate the bot account under User & Teams → Users.
2. Click the vertical ellipsis (⋮) on the far right of the user row.
3. Delete User 

---

Global Metric Calculations

Why
Determines how PR Size, Cycle Time, Pickup Time, Review Time, and Deploy Time aggregate.

Where to configure
Configure at Company Settings → General → Metrics Calculation.

Options & Examples

• Average – Sum ÷ count
  Example: 4 PRs took 2, 4, 6, and 8 hours → (2 + 4 + 6 + 8) ÷ 4 = 5 hours average.
• Median – Middle value
  Example: PR merge times are 2, 4, 6, 8, 10 → Median = 6 hours.
• 75th Percentile – 75% of PRs are faster than or equal to this.
  Example: Most PRs take 2–6 hours but a few take 10+ → 75th percentile ≈ 6 hours (captures the “typical upper range”).
• 90th Percentile – 90% of PRs are faster than or equal to this.
  Example: Most PRs take 2–8 hours, but a few outliers take 20+ → 90th percentile ≈ 8 hours (shows performance excluding rare outliers).

How to choose the right calculation method

Different engineering teams prefer different aggregation strategies depending on their size, workflow variability, and how sensitive they are to outliers. Below is guidance to help you choose the method that best reflects your team’s “true” performance.

• Average (Mean)
  Best when your team’s PR sizes and cycle times are relatively consistent. 
  Why choose it: You want a simple, familiar metric and your data does not contain extreme outliers.
• Median
  A stable representation of your “typical” PR because it ignores outliers on both ends. 
  Why choose it: Your workflow produces occasional very large or unusual PRs, and you don’t want those to skew the overall metric.
• 75th Percentile (Industry Standard)
  Captures the performance of most PRs while still reflecting friction in the system. 
  Why choose it: You want a balanced view that smooths outliers but still highlights when work takes longer than expected. Most DORA-focused teams prefer this.
• 90th Percentile
  Highlights the slowest part of your process without being dominated by true one-off outliers. 
  Why choose it: You want more sensitivity to delays — great for teams optimizing flow efficiency or monitoring tail behavior.