Controlling Nitpickiness

Fresh

Fine-tune Greptile's review strictness, filter comment types, ignore files, and configure triggers. Get high-signal code reviews without the noise.

With noise control, Greptile limits reviews to high-signal insights, skipping low impact or repetitive feedback.

Configuration Options Overview

You can fine-tune review behavior with these configuration options in .greptile/config.json or greptile.json:

Parameter	Type	Description
strictness	number	Filters comments by importance (1-3 scale)
commentTypes	array	Categories of feedback to generate
ignorePatterns	string	Files/folders to skip (newline-separated patterns)
triggerOnUpdates	boolean	Review on every commit, not just PR open
skipReview	string	Set to "AUTOMATIC" for manual-only reviews

Severity Threshold Settings

Control how strict Greptile is about leaving comments with the strictness setting (1–3).

1. Low (Verbose)

**Comments on everything (low threshold).**

Perfect for initial setup or deep reviews where you want every potential issue flagged.

2. Default (Recommended)

**Provides moderate filtering (default).**

Balanced approach highlighting real issues while filtering common noise. We recommend starting here.

3. High (Critical)

**Shows only the most critical issues (high threshold).**

Ideal for final reviews or teams that want minimal interruption.

How to Configure

.greptile/ (Recommended)

Set `strictness` in `.greptile/config.json` at your repository root or any subdirectory:

```json .greptile/config.json theme={}
{
  "strictness": 2
}
```

* `1` = verbose (all issues)
* `2` = balanced (default)
* `3` = critical only

In a monorepo, child directories can override the root setting, for example, a `packages/db/.greptile/config.json` with `"strictness": 1` makes database reviews stricter while the rest of the repo stays at `2`. See [Cascading Configuration](/code-review/greptile-config#cascading-configuration).

greptile.json

Create `greptile.json` at your repository root:

```json theme={}
{
  "strictness": 2
}
```

* `1` = verbose (all issues)
* `2` = balanced (default)
* `3` = critical only

Note

  This overrides dashboard settings for this repository.

Dashboard

Go to **Code Review Settings** in the sidebar. The strictness slider is in the **When Greptile Reviews** section.

!Code Review Settings

Comment Type Filtering

Filter which categories of feedback Greptile provides. All types are enabled by default.

Available comment types:

• logic - Business logic issues, algorithmic problems, potential bugs
• syntax - Language-specific best practices, proper usage patterns
• style - Code formatting, naming conventions, structural consistency
• info - Informational comments about code context and patterns

How to Configure

.greptile/ (Recommended)

Set `commentTypes` in `.greptile/config.json`:

```json .greptile/config.json theme={}
{
  "commentTypes": ["logic", "syntax"]
}
```

This array replaces the default, only the types you list will appear. Like strictness, child directories can override this for their own scope.

greptile.json

**Only critical issues:**

```json theme={}
{
  "commentTypes": ["logic"]
}
```

**Code quality without style nitpicks:**

```json theme={}
{
  "commentTypes": ["logic", "syntax"]
}
```

**Everything (default):**

```json theme={}
{
  "commentTypes": ["logic", "syntax", "style", "info"]
}
```

Dashboard

Go to **Code Review Settings** in the sidebar. Toggle **Syntax**, **Logic**, and **Style** buttons in the **What should Greptile comment on?** section.

Ignore Patterns

Exclude files that don't need review to speed up analysis and reduce noise.

{
  "ignorePatterns": "*.generated.*\n**/*.test.js\n**/node_modules/**\n*.config.js\npackage-lock.json\n*.md"
}

Common patterns to ignore:

• *.generated.* - Generated code
• **/*.test.js - Test files
• **/node_modules/** - Dependencies
• *.config.js - Config files
• package-lock.json - Lock files
• *.md - Documentation

Impact: Ignoring generated/vendor files can speed up reviews by 30-50% and eliminate irrelevant comments.

Warning

ignorePatterns will only ignore those files during PR review. Greptile will still index them while indexing your repository, which can lead to other errors. For instance, in the case of large binary files. Reach out to Greptile support.

Trigger Configuration

Control when Greptile performs reviews. This affects developer workflow and review frequency.

.greptile/ (Recommended)

Set trigger behavior in `.greptile/config.json`:

```json .greptile/config.json theme={}
{
  "triggerOnUpdates": true
}
```

To disable automatic reviews entirely (manual trigger via `@greptileai` only):

```json .greptile/config.json theme={}
{
  "skipReview": "AUTOMATIC"
}
```

greptile.json

**Review on every commit:**

```json theme={}
{
  "triggerOnUpdates": true
}
```

**Manual trigger only (skip automatic reviews):**

```json theme={}
{
  "skipReview": "AUTOMATIC"
}
```

* `triggerOnUpdates` - When `true`, reviews on each push (not just PR open)
* `skipReview: "AUTOMATIC"` - Skips automatic reviews, only triggers via `@greptileai`

Dashboard

Go to **Code Review Settings** in the sidebar. Toggle **Auto-review on new commits** and **Review draft pull requests** in the **When Greptile Reviews** section.

Tip

Start with dashboard defaults, then add a .greptile/ folder to repos that need custom settings.

Troubleshooting

Settings not taking effect

**Check these in order:**

1. If using `greptile.json`, did you commit and push it?
2. Are you looking at a new PR? Settings don't affect existing reviews
3. Wait 2-3 minutes - config changes aren't always instant

**Dashboard settings not working?**

* Check if the repo has a `greptile.json` (it overrides dashboard)
* Verify you saved the settings (look for confirmation message)

Still too many comments with strictness: 3

**Progressive solutions:**

1. Reduce comment types to `["logic"]` only
2. Add more ignore patterns for generated/test files
3. Consider `skipReview: "AUTOMATIC"` for non-critical repos
4. Give the learning system 2-3 weeks to adapt to your reactions

Missing important issues

**Check these settings:**

1. Is strictness too high? Try reducing by 1
2. Are all comment types enabled that you need?
3. Check ignore patterns - are they too broad?
4. Has the team been giving 👍 to important catches?

Different teams want different settings

**Best practice:**

1. Set organization-wide defaults in **Code Review Settings** at the org level (strictness: 2, all types)
2. Teams inherit org settings by default. Customize specific teams in their own **Code Review Settings**
3. Use **Inheritance & Sync** on the team settings page to reset a team to match the org when needed
4. For per-directory overrides within a repo, use `.greptile/` folders, each package in a monorepo can have its own strictness and comment types

See [Organizations & Teams](/code-review/team-setup-basics#syncing-settings-across-teams) for how inheritance works, and [Cascading Configuration](/code-review/greptile-config#cascading-configuration) for per-directory overrides.

Excluded authors still getting reviewed

**In Dashboard:**
Go to **Code Review Settings** > **What should Greptile comment on?** > **Fine-tuning**. Set the filter to **Authors** / **Exclude** and add:

* `dependabot[bot]`
* `renovate[bot]`
* Any other bot accounts

**Note:** This is dashboard-only, not available in greptile.json

Reviews triggering on disabled/release branches

**Solutions:**

1. Add release branches to excluded branches in dashboard
2. Use `greptile.json` with branch-specific rules
3. Set `skipReview: "AUTOMATIC"` for release repos

What's next?

• .greptile/ Configuration → for cascading per-directory settings
• Train the learning system → to automatically reduce noise over time
• Add custom standards → for team-specific rules
• Set up pattern repositories → for cross-repo context

Source

Mirrored from the official Greptile documentation. Self-contained reference copy.