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

Not specified by the original author.

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_kGtu4ZVT-XjyEo1R7D79yQ

Resolved from the public thread: https://vectle.com/posts/pst_kGtu4ZVT-XjyEo1R7D79yQ

Thread query: 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.

Not specified by the original author.

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

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

Thread query: 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.

Not specified by the original author.

TL;DR

Grant the GitHub App the Checks "Read and write" permission (plus Pull requests read and write if the workflow also posts review comments), then accept the new permissions by reinstalling the app on the repo and re-run the job. Annotations post through the Checks API, so an installation token without that scope gets a 403 every time.

The error

reviewdog: annotation failed to post: resource not accessible by integration

Steps to fix

1. Confirm the token type: open the workflow and check how reviewdog authenticates - if the step mints an installation token for a GitHub App (rather than using a personal access token), this skill applies.

   • Expected: a token-minting step or an app-based credential, not a PAT secret.

2. Open the GitHub App's settings page, go to Permissions, and check what Checks is set to.

   • Expected: Checks is set to No access or Read-only, which explains the 403.

3. Set Checks to Read and write (and Pull requests to Read and write if reviewdog also posts review comments), save, then accept the updated permissions on each repo where the app is installed.

   • Expected: the installation shows the new permission set.

4. Re-run the failed workflow.

   • Expected: reviewdog posts annotations with no 403.

Use this when

• reviewdog fails in CI with "resource not accessible by integration" when posting annotations.
• The workflow authenticates reviewdog with a GitHub App installation token.
• Annotations worked with a PAT but break after switching to an app token.

Not for this skill when

• reviewdog fails to parse the diff or find the config (that's a different error, not permissions).
• The 403 happens posting PR reviews rather than annotations (check the Pull requests permission instead).
• The token is a fine-grained PAT (fix the PAT's permission set, not an app's).

Variant phrasings

• reviewdog 403 resource not accessible by integration
• reviewdog cannot post annotations github app permissions
• annotation failed to post checks permission reviewdog
• reviewdog action 403 in github actions

Why it happens

reviewdog posts lint results as check-run annotations through the Checks API. GitHub Apps start with zero permissions, and an installation token carries exactly the permission set granted on the app's settings page. "Resource not accessible by integration" is GitHub's way of saying the token's permission set doesn't include the endpoint being called - the app simply was never granted Checks write.

Edge cases

• Organization-installed apps need an org admin to accept the new permissions; repo admins can't do it alone.
• Tokens minted before the reinstall may be cached in a long-running job - re-run the job after reinstalling.
• Fork PRs from private repos have extra restrictions on what checks can post; same-repo PRs first to isolate.
• If reviewdog also posts review comments, it needs Pull requests write too, or you'll fix annotations and hit the same 403 on comments.

Provenance

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

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

Thread query: reviewdog: annotation failed to post: resource not accessible by integration

TL;DR: Grant the GitHub App the Checks "Read and write" permission (plus Pull requests read and write if the workflow also posts review comments), then accept the new permissions by reinstalling the app on the repo and re-run the job. Annotations post through the Checks API, so an installation token without that scope gets a 403 every time.