<p>A Jenkins build has the same 200 TPU limit as an Azure DevOps build, in that they both get the standard user limit.</p>
<p>Azure builds treat each pipeline as a separate user, so if you have many pipelines using the same account it would mean sharing the limit across all builds.</p>
<p>200 TPU is <em>a lot</em>, so it's worth checking to see if you are doing something super inefficient in the build that may have gone unnoticed when things had no limit. For example, are you calling a git operation in a loop in there?</p>
<p>If you are only running one build, it just be doing something huge. These &quot;TPU&quot; values are very close to being equivalent to Azure database DTUs. That's a lot of activity... more than I'd expect one user to be able to generate unless your build churns git operations, or the repo has tons of large files, or some other &quot;unusual&quot; condition.</p>

CC BY-SA 4.0
2023-05-25T07:54:15.293Z
Thx for the answer. We did migrate 160 Gitblit repositories to Azure Repos... And we have a couple of big repositories (+1Gb). So maybe that was the reason the 200 TPU was  hit.... The day after the migration, we no longer saw that error.
Lieven Cardoen
CC BY-SA 4.0
2023-05-25T09:32:12.353Z
That's good news - did you do the migrations with the same user account? If so, that's likely to be the cause and your normal builds shouldn't hit the limit.
Fenton
CC BY-SA 4.0
2023-05-25T11:41:47.570Z
Yes. All migrations were done with the same account. Thx!
Lieven Cardoen
CC BY-SA 4.0
2023-05-25T05:43:18.113Z
2023-05-25T05:43:18.113Z
Fenton
<p>We were using an on premise Jenkins against an on premise GitBlit. This worked fine. Last week we migrated from GitBlit to Azure DevOps.</p>
<p>Our Jenkins Jobs now run with the PAT of a 'fake' Azure Account (not the 'Build Service Account' because that one can't be used by an on premise Jenkins). So for Azure DevOps this is a regular user. We found no other way to set this up. Using the PAT of an employee was not really a good option.</p>
<p>Problem now is that we are constantly hitting the Rate Limites with following error:</p>
<blockquote>
<p>Request was blocked due to exceeding usage of resource 'ATCPU' in
namespace 'VSID'. For more information on why your request was
blocked, see the topic &quot;Rate limits&quot; on the Microsoft Web site
(<a href="https://go.microsoft.com/fwlink/?LinkId=823950" rel="nofollow noreferrer">https://go.microsoft.com/fwlink/?LinkId=823950</a>).</p>
</blockquote>
<p><a href="https://i.sstatic.net/3qDIK.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/3qDIK.png" alt="enter image description here" /></a></p>
<p>After which the Jenkins Job fails.</p>
<p>This is a game stopper in our migration to Azure DevOps because there seems to be no way to adjust those Rate limits for a given user...</p>
<p>Do you have recommendations? Is there a way to increase those limits?</p>
<p>In the screenshot, what does the Count and TSTUs exactly mean? We have the idea that it's not about how many bytes are transferred but rather the number of Git Operations.</p>
<p>Our Jenkins Jobs mainly clone Git Repositories with the usage of local mirrors.</p>

<jenkins><azure-devops><azure><git>
Is there a way to increase Rate limits on Azure DevOps?
Lieven Cardoen
# Is there a way to increase Rate limits on Azure DevOps?

(Asked by: username_0 on 2023-05-24)

We were using an on premise Jenkins against an on premise GitBlit. This worked fine. Last week we migrated from GitBlit to Azure DevOps.

Our Jenkins Jobs now run with the PAT of a 'fake' Azure Account (not the 'Build Service Account' because that one can't be used by an on premise Jenkins). So for Azure DevOps this is a regular user. We found no other way to set this up. Using the PAT of an employee was not really a good option.

Problem now is that we are constantly hitting the Rate Limites with following error:

> Request was blocked due to exceeding usage of resource 'ATCPU' in
> namespace 'VSID'. For more information on why your request was
> blocked, see the topic "Rate limits" on the Microsoft Web site
> (<https://go.microsoft.com/fwlink/?LinkId=823950>).

[![enter image description here](https://i.sstatic.net/3qDIK.png)](https://i.sstatic.net/3qDIK.png)

After which the Jenkins Job fails.

This is a game stopper in our migration to Azure DevOps because there seems to be no way to adjust those Rate limits for a given user...

Do you have recommendations? Is there a way to increase those limits?

In the screenshot, what does the Count and TSTUs exactly mean? We have the idea that it's not about how many bytes are transferred but rather the number of Git Operations.

Our Jenkins Jobs mainly clone Git Repositories with the usage of local mirrors.

**Tags:** jenkins, azure-devops, azure, git


---

## 1 answers

### Answer by username_1 on 2023-05-25. Score: 1

A Jenkins build has the same 200 TPU limit as an Azure DevOps build, in that they both get the standard user limit.

Azure builds treat each pipeline as a separate user, so if you have many pipelines using the same account it would mean sharing the limit across all builds.

200 TPU is *a lot*, so it's worth checking to see if you are doing something super inefficient in the build that may have gone unnoticed when things had no limit. For example, are you calling a git operation in a loop in there?

If you are only running one build, it just be doing something huge. These "TPU" values are very close to being equivalent to Azure database DTUs. That's a lot of activity... more than I'd expect one user to be able to generate unless your build churns git operations, or the repo has tons of large files, or some other "unusual" condition.

> **Comments:**
> **username_0**: Thx for the answer. We did migrate 160 Gitblit repositories to Azure Repos... And we have a couple of big repositories (+1Gb). So maybe that was the reason the 200 TPU was  hit.... The day after the migration, we no longer saw that error.  
> **username_1**: That's good news - did you do the migrations with the same user account? If so, that's likely to be the cause and your normal builds shouldn't hit the limit.  
> **username_0**: Yes. All migrations were done with the same account. Thx!  

---

