A quality gate is a CI-time check that fails the build when a scan’s findings exceed configured thresholds. The gate is defined by per-severity count limits (plus code-quality and license limits) — not by a single “severity floor”. Out of the box it fails on any CRITICAL finding or more than 10 HIGH findings. Configurable per-repo or org-wide.

​
Default policy

Until you save a config, the gate applies these built-in defaults automatically — nothing is written on a CI request. Click Load Defaults in the dashboard to persist them as an editable org default. Severity thresholds are count limits where -1 means no limit.
ThresholdDefaultFails when
Max critical findings0Any critical finding
Max high findings10More than 10 high findings
Max medium findings-1 (no limit)—
Max low findings-1 (no limit)—
Max cyclomatic complexity25Any function over 25
Max duplication5%Duplication above 5%
Blocked licensesnoneA dependency uses a blocked license
New-code-only modeoff(see New code)
By default the gate is evaluated against the whole codebase’s severity counts, so pre-existing findings can keep the gate red until they’re fixed. To gate only on new findings, turn on new-code mode (below). Configs resolve per-repo first, then org default. A per-repo config overrides the org default for that repository; repos without their own config inherit the org default. In a monorepo you can go one level finer and give each component its own gate — see Monorepo components.

​
Configure from the dashboard

Quality gates live under CI/CD → Quality Gates (/ci-cd?activeTab=gates). Each config is either the Organization Default (no repository set) or a per-repo override. There’s no in-repo config file to maintain — settings persist in TigerGate.

​
Org-default policy

Applies to every repo until a per-repo config overrides it.
1

Open CI/CD → Quality Gates

If no configs exist yet, click Load Defaults to seed the standard thresholds, or New Quality Gate to define your own.
2

Leave the Repository field blank

A config with no repository selected is the Organization Default.
3

Set the severity thresholds

Max Critical / High / Medium / Low — the maximum number of findings at each severity before the build fails. Enter -1 for no limit.
4

Set the code-quality thresholds

Max Complexity (per-function cyclomatic complexity) and Max Duplication %. -1 disables either check.
5

(Optional) Block licenses

Blocked Licenses — a comma-separated list (e.g. GPL-3.0, AGPL-3.0). Any dependency in the SBOM carrying a blocked license fails the gate.
6

Save

Changes apply on the next scan.

​
Per-repo override

When one repo needs a stricter (or looser) policy than the org default.
1

Click 'New Quality Gate'

On the CI/CD → Quality Gates tab.
2

Pick the repository

Choose the repo from the Repository dropdown. This config now applies to that repo instead of the org default.
3

Adjust the thresholds and save

Set whatever thresholds differ from the org default. To revert, delete the per-repo config — the repo falls back to the org default.

​
Threshold reference

The gate evaluates each configured threshold independently and fails if any is exceeded.
ThresholdOperatorNotes
max_critical / max_high / max_medium / max_lowcount ≤ limit-1 = no limit
max_complexitymax cyclomatic complexity ≤ limitevaluated from the quality scan; -1/0 skips
max_duplicationduplication % ≤ limitevaluated from the quality scan; -1/0 skips
min_coveragecoverage % ≥ limitonly when a coverage report is uploaded; 0 skips
blocked_licenses0 packages with a blocked licenseskipped when the list is empty
INFO findings are not counted at any severity threshold.

​
New code (clean-as-you-code)

By default the gate looks at the whole codebase. Turn on New code only on a config to gate only findings introduced after a baseline — legacy debt is tolerated, but new problems block the PR (the “clean as you code” pattern). When New code only is enabled the gate uses the new-code thresholds (nc_max_critical, nc_max_high, nc_max_medium, nc_max_low) and an optional new-code coverage floor (nc_min_coverage) instead of the whole-codebase counts. The default new-code thresholds are 0 criticals and 0 highs. New-code mode pairs with the CLI’s scan scope — run tigergate scan --scan-scope diff (or the default auto, which also uploads a new-code summary alongside the full results) so the changed-code findings the gate needs are computed. The base branch is auto-detected from the CI environment (GitHub GITHUB_BASE_REF, GitLab CI_MERGE_REQUEST_TARGET_BRANCH_NAME, Azure SYSTEM_PULLREQUEST_TARGETBRANCH, Bitbucket BITBUCKET_PR_DESTINATION_BRANCH), falling back to HEAD~1.
New-code mode needs a new-code signal to measure. It gets one from a diff or auto scan, or from a new-code baseline set on the repo+branch. With neither, the severity checks are reported as skipped — not passed — and the gate response carries a warning that the CLI prints. If you see that warning, the build was not actually evaluated: add --scan-scope diff or set a baseline.
If you don’t want a leak period at all, --scan-scope diff on its own is often the simpler choice: it filters the uploaded findings to the PR’s changes, so the ordinary thresholds already only see new code and no baseline is involved.

​
Monorepo components

In a single-gate monorepo a frontend PR fails because services/api still carries a pre-existing critical — a finding the frontend team can neither fix nor merge past. Scoping gates to components fixes that: each component owns a set of paths, has its own thresholds, and posts its own status check. Any quality gate config takes two extra fields:
FieldMeaning
ComponentThe component key, e.g. web. Blank means the config applies to the whole repository.
Component pathsComma-separated, repo-root-relative paths the component owns, e.g. apps/web, libs/shared. CI jobs for this component inherit them.
Configs then resolve most-specific-first:
  1. Repository matches and component matches
  2. Repository matches, component blank — the repo-wide gate
  3. Repository blank and component matches — an org-wide rule for that component name
  4. Repository blank, component blank — the Organization Default
A component with no config of its own inherits the repo-wide gate, and the CLI logs which config judged the run (Quality gate: acme/mono / component web) rather than leaving it to guesswork. New-code mode and every threshold on this page apply per component once one is configured — a component’s max_high counts only findings under that component’s paths. See Monorepos for how a component decides whether a PR concerns it, what a component run contains, and branch-protection setup. CI recipes are in CI/CD integration.

​
License blocking

List SPDX license identifiers under Blocked Licenses on any config. During the gate check TigerGate scans the uploaded SBOM and fails the build if any package declares one of the blocked licenses, listing the offending packages in the gate summary. Empty by default (no license gating).

​
Coverage

If you upload coverage reports, two coverage checks become available:
CheckConfigFires when
Minimum line coveragemin_coverageOverall coverage falls below the configured floor
New-code coveragenc_min_coverage (new-code mode)Coverage on the changed lines falls below the floor
Both are opt-in. A 0 floor skips the check, and a check is skipped (not failed) when the metric can’t be computed from the uploaded report.

​
Running the gate

Already wired by the CI snippets. The gate runs by default on every scan. The CLI exits non-zero when the server-side gate fails, which is what blocks the merge: 
tigergate scan --type all --upload
echo "exit code: $?"   # 0 = pass, non-zero = gate failed (or scan error)
The gate summary in the CLI’s stdout lists each condition (✓ ok, ✗ failed, – no limit) followed by the finding counts by severity: 
──────────────────────────────────────────────────
  Quality Gate: FAILED
──────────────────────────────────────────────────
  ✗ critical_findings    1       (max 0)
  ✗ high_findings        12      (max 10)
  ✗ duplication          6       (max 5)
  – medium_findings              (no limit)
──────────────────────────────────────────────────
  Conditions: 3 passed · 3 failed · 1 skipped
──────────────────────────────────────────────────
  Findings by severity (total: 42)
    critical : 1
    high     : 12
    medium   : 15
    low      : 14
    info     : 0
──────────────────────────────────────────────────

​
Report-only mode

To run the scan and upload results without failing the build, pass --quality-gate=false. The scan still runs and uploads, but the CLI always exits 0 — nothing blocks the merge. Use this during the first weeks of onboarding so the team can triage the backlog before the gate starts blocking, then drop the flag to enforce. 
tigergate scan --type all --upload --quality-gate=false

​
Notifications

Failed gates can notify the channels configured for CI in CI/CD (or under Notifications). Each channel is only usable once its integration is active:
ChannelNotes
Slack / Microsoft TeamsPosts scan + gate results to a channel
Email on failureEmails on a failed quality gate
PagerDuty on criticalPages when critical findings are present
WebhookDelivers the result to a custom endpoint
A severity threshold (default high) controls the minimum finding severity that triggers a notification.