SonarCloud Azure DevOps pull request decoration missing decorations when many issues were found

Hello SonarCloud,

We are using SonarCloud to decorate pull requests in Azure DevOps. This works fine if there are only a small amount, say about 20-25, issues found for a scanned project. Then all these 20-25 comments are placed in the pull request. No problem. But when more issues, say 100, are found in a pull requests it doesn’t decorate them all but seems to split them up. It looks like it limits the pull request decoration to about 20-25 comments. When we fix the code issues found and a new scan is done, it finds the next 20-25 issues and decorates the pull request with those issues found. In say 100 issues are found, we would expect all those 100 issues to be decorated in the pull request immediately. If we look at our pull request branch in SonarCloud itself all issues are immediately reported. It looks like the pull request decoration in Azure DevOps is then broken up into smaller steps.

A similar issue was posted last year at

This is quite annoying because we would want to see all issues being decorated when we do the initial pull request so we can solve all issues at once.

Hopefully you can point us in the right direction or help us solve this problem.

With kind regards,


Welcome to the community!

I can see in the code that we decorate max 20 issues on Azure DevOps. I don’t know why we have this limit, I suspect API limits or fear of noise may be important factors. I’ll ask my colleagues and keep you posted.

What if there are 1000+ issues? Would you want all issues to be decorated, without a limit?

Thank you for your response.

Good to read that there is indeed a hard coded limit which explains our observation. I discussed this with a colleague of mine and would it be an idea to at least show a comment/decoration in the pull request when more than 20 issues are found? Where the comment says something like “The maximum amount of decorations (20) has been reached, please see SonarCloud for the full report.”?

Or would it be an idea if the amount of decorations can be made configurable, so that we can decide how many decorations there should be made (via a properties configuration in an Azure DevOps pipeline task)?

Regarding your question about when 1000+ issues are found, I think that is indeed an extreme situation which you do not want. But the limit of 20 is relatively low I think.

1 Like

Hello together,

I would expect at least as many comments as set to fail the quality gate.

If there are 40 new issues allowed on new code without failing the quality gate, I would to have these 40 issues in the PR.

If the quality gate failed, then it would be acceptable IMHO to be redicrected to the SonarQube web UI to see every issue.

Is there any update on this issue?


We will increase the current limit of 20 comments, ticket has been created here :

We’ll let you know the progress of it.

Thank you.

Hello there,

Quick update just to let you know that we’ve increased the number of comments for a PR to 50 + documented it in our Azure DevOps extension doc


1 Like