## TL;DR
GitHub caps check runs at 50 annotations and reviewdog posts one per finding, so a noisy linter blows past the cap and the API rejects the extras. Cut the volume: only annotate errors, filter to changed lines, or split the linter into smaller check runs. The cap is GitHub-side and cannot be raised, so the fix is always fewer annotations.

## The error
```text
error: check runs may not have more than 50 annotations: reviewdog annotation limit
```

## Steps

### 1. Count how many findings the linter produces
Run the linter locally on the PR diff and count the findings.
Expected output: well over 50 findings, which confirms the volume is the problem.

### 2. Annotate errors only
Pass a fail level so warnings and info-level notes stay in the log but never become annotations:
```bash
reviewdog -reporter=github-pr-check -fail-level=error
```
Expected output: the annotation count drops to the error-level findings only.

### 3. Filter to changed lines
Use diff-context filtering so findings on untouched lines are skipped:
```bash
reviewdog -filter-mode=diff_context
```
Expected output: findings outside the PR diff no longer consume annotation budget.

### 4. Split the linter into smaller runs
If one linter still produces 50+ errors, run it per directory or per package so each invocation gets its own check run and its own 50-annotation budget.
Expected output: several smaller check runs, each under the cap.

### 5. Re-run the review step
Push the flag changes and re-run.
Expected output: the check run completes and the annotations that remain are all posted.

## When to use
- The exact 50-annotation error on a reviewdog check run
- A new linter or a stricter ruleset suddenly floods PRs
- Large PRs that touch many files

## When not to use
- Annotation permission errors (resource not accessible)
- Annotations landing on the wrong lines (line mapping problem)
- Linter crashes or config errors

## Tool compatibility
- reviewdog v0.14 and later (fail level and filter mode flags)
- github-pr-check and github-pr-review reporters
- GitHub check runs API (the 50-annotation cap is platform-wide)

## Variant phrasings
### reviewdog too many annotations
Same fix. Fewer findings per check run is the only lever.

### check run failed with annotation limit on large PR
Large PRs multiply findings. Combine steps 2 and 3, then split per step 4.

### GitHub API 422 on check run annotations
The 422 is the cap being enforced. It is not a payload bug.

## Why it happens
GitHub limits each check run to 50 annotations to keep the PR UI usable. reviewdog maps every linter finding to an annotation by default, so enabling a noisy ruleset or reviewing a huge diff exceeds the cap and the API rejects the batch.

## Edge cases
- The cap counts annotations per check run, not per PR. Two linters in one run share the budget.
- Dedupe first: some linters report the same finding per file and per package. Deduping can halve the count.
- fail-level error still fails the step on errors only, which is usually what a gate wants anyway.
- Very first PR on a legacy codebase: consider a baseline or new-issues-only mode instead of annotating all existing debt.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_2u0QHzxIlMRCMx1m0KoImQ