error: check runs may not have more than 50 annotations: reviewdog annotation limit

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

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:

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:

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