Work tracking, process, and project limits
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
This article defines operational and object limits placed on work tracking operations and work tracking customization. In addition to the specified hard limits on specific objects, some practical limits apply. When you customize work item types (WITs), consider the limits placed on objects.
Work items and queries
When you define work items or running queries, keep the following operational limits in mind:
| Object | Limit |
|---|---|
| Attachments added to a work item | 100 |
| Attachment size | 60 MB |
| Long text field | 1-M characters |
| Query execution time | 30 seconds |
| Query results | 20,000 items |
| Query length | 32,000 characters |
| Shared queries under a folder | 999 queries |
| Work item links assigned to a work item | 1,000 |
| Work item tags assigned to a work item | 100 |
| Work item revisions (REST API) | 10,000 |
| Favorite queries per project | 200 queries |
The REST API for Azure DevOps Services enforces a work item revision limit of 10,000 updates. This limit restricts updates made through the REST API, but updates from the web portal aren't affected.
| Object | Limit |
|---|---|
| Long text field | 1-M characters |
| Work item tags assigned to a work item | 100 |
| Work item links assigned to a work item | 1,000 |
| Attachments added to a work item | 100 |
| Attachment size | 4 MB to 2 GB |
| Query execution time | 6 minutes |
| Query results | 20,000 items |
| Query length | 32,000 characters |
| Shared queries under a folder | 999 queries |
| Favorite queries per project | 200 queries |
The default maximum attachment size is 4 MB. You can change the maximum size up to 2 GB.
To improve query performance, see Define a query/Best practices.
Backlogs, boards, dashboards, and teams
When you work with teams, work item tags, backlogs, and boards, the following operational display and object limits apply.
| User interface | Limit |
|---|---|
| Backlogs | 10,000 work items |
| Boards | 1,000 cards (excluding those cards in the Proposed and Completedworkflow state categories) |
| Taskboard | 1,000 tasks |
| Area Paths | 10,000 per project |
| Area Path Depth | 14 |
| Area Paths per team | 300 |
| Iteration Paths | 10,000 per project |
| Iteration Path Depth | 14 |
| Iteration Paths per team | 300 |
| Project Dashboards | 500 per project |
| Team Dashboards | 500 per team |
| Teams | 5,000 per project |
| Work item tags | 150,000 tag definitions per organization or collection |
| Delivery plans per project | 1,000 |
| Templates per work item type | 100 |
Each backlog can display up to 10,000 work items. This limit applies to what the backlog can display, not to the number of work items you can define, as there's no specific limit. If your backlog exceeds this limit, consider adding a team and moving some work items to the new team's backlog.
Other notes:
- Completed or closed work items don't display on backlogs and boards once their Changed Date is older than a year. You can still list these items using a query. To make them show up on a backlog or board, make a minor change to reset the display clock.
- Avoid nesting backlog items of the same type. For more information, see Fix reordering and nesting issues.
- Avoid assigning the same area paths to more than one team. For more information, see Limitations of multi-team board views.
- By default, work item limits might be set to lower values initially.
When you work with teams, work item tags, backlogs, and boards, the following operational limits apply. Default and maximum limits.
| User interface | Limit |
|---|---|
| Backlogs | 999 work items |
| Boards | 400 cards |
| Dashboards per project | 500 |
| Taskboard | 800 work items |
| Teams | 5,000 per project |
| Work item tags | 150,000 tag definitions per project |
| Templates per work item type | 100 |
Each backlog can display up to 999 work items. If your backlog exceeds this limit, consider creating a team and moving some of the work items to the new team's backlog.
Other notes:
- Avoid nesting backlog items of the same type. For more information, see Fix reordering and nesting issues.
- Avoid assigning the same area paths to multiple teams. For more information, see Limitations of multi-team board views.
For the On-premises XML process model, you can modify the backlog and Taskboard limits by editing the ProcessConfiguration.xml file. For details, see Process configuration XML element reference.
Projects
Azure DevOps Services limits each organization to 1,000 projects per organization, an increase over the previous limit of 300 projects.
Note
Above 300 projects, certain experiences, like connecting to a project from Visual Studio, may degrade. For on-premises Azure DevOps Server, there are no hard limits, but performance issues may arise as the number of projects nears 300. When migrating to Azure DevOps Services, observe the maximum limit of 1,000 projects. If your collection exceeds this limit, split the collection or delete older projects.
For more information, see Migrate data from Azure DevOps Server to Azure DevOps Services.
Process customization
Many limits are imposed on the number of objects you can define for a process. For more information, see Customize your work tracking experience.
The following table lists the maximum number of objects you can define for the Inheritance and Hosted XML process models. While these are hard limits, practical limits might also apply.
| Object | Inheritance | Hosted XML |
|---|---|---|
| Number of processes you can have in an organization | 128 | 64 |
| Work item types defined for a process | 64 | 64 |
| Fields defined for an organization | 8192 | 8192 |
| Fields defined for a process | 1024 | 1024 |
| Fields defined for a work item type | 1024 | 1024 |
| Picklists defined for an organization or collection | 2048 | - |
| Picklist items defined for a list | 2048 | 2048 |
| Picklist item character length | 256 | - |
| Workflow states defined for a work item type | 32 | 16 |
| Rules defined for a work item type | 1024 | 1024 |
| Actions defined for a rule | 10 | 10 |
| Portfolio backlog levels defined for a process | 5 | 5 |
| Categories defined for a process | - | 32 |
| Global lists defined for a process | - | 256 |
| List items defined within a global list | - | 1024 |
| Work item attachment size | 60 MB | 60 MB |
For other restrictions and conformance requirements of the Hosted XML process model, see Customize a process when using Hosted XML.
Note
For the Hosted XML process model, you can define approximately 10,000 items across all global lists specified in all WITs.
The following table lists the maximum number of objects you can define for the Inheritance and On-premises XML process models. While these are hard limits, practical limits might also apply.
| Object | Inheritance | On-premises XML |
|---|---|---|
| Number of processes you can have in an organization | 64 | 64 |
| Work item types defined for a process | 64 | 64 |
| Fields defined for a collection | 8192 | 1024 |
| Fields defined for a process | 1024 | 1024 |
| Fields defined for a work item type | 1024 | 1024 |
| Picklists defined for a collection | 1024 | N/A |
| Picklist items defined for a list | 2048 | 2048 |
| Picklist item character length | 256 | N/A |
| Workflow states defined for a work item type | 32 | 16 |
| Rules defined for a work item type | 1024 | 1024 |
| Portfolio backlog levels defined for a process | 5 | 5 |
| Categories defined for a process | N/A | 32 |
| Global lists defined for a process | N/A | 256 |
| List items defined within a global list | N/A | 1024 |
Note
For the On-premises XML process model, you can define an approximate total of 10K items for all global lists specified across all WITs.
Practical limits
To minimize performance issues, we recommend following this guidance:
- Limit the number of custom fields you define. All custom fields contribute to the total allowed for a process, collection, or organization. You can specify different behaviors, such as rules and picklists, for the same field in different WITs.
- Limit the number of rules you define for a WIT. While you can create multiple rules for a WIT, additional rules can negatively affect performance when users add or modify work items. When users save work items, the system validates all rules associated with the fields for that work item type. In some cases, the rule validation expression may be too complex for SQL to evaluate efficiently.
- Limit the number of custom WITs you define.
- Limit the number of custom fields you define. All custom fields contribute to the total allowed for a process, collection, or organization. You can specify different behaviors, such as rules and picklists, for the same field in different WITs.
- Limit the number of rules you define for a WIT. While you can create multiple rules for a WIT, additional rules can negatively affect performance when users add or modify work items. When users save work items, the system validates all rules associated with the fields for that work item type. In some cases, the rule validation expression may be too complex for SQL to evaluate efficiently.
- Limit the number of custom WITs you define.
- Limit the number of reportable fields you define. Reportable fields can impact the performance of your data warehouse.
Note
Work Item Rules Validation Exceeds SQL Limits: A single SQL expression is defined per project to validate work items whenever they are created or updated. This expression grows with the number of rules specified for all work item types in the project. Each behavioral qualifier for a field increases the number of sub-expressions. Nested rules, rules that apply only on a transition, or rules conditioned on the value of another field add more conditions to an IF statement. Once the expression reaches a certain size or complexity, SQL can no longer evaluate it and generates an error. To resolve this error, remove some WITs or eliminate some rules.
Rate limits
To reduce costs and enhance scalability and performance, Azure DevOps Services, like many Software-as-a-Service solutions, uses multi-tenancy. To ensure good performance and minimize the risk of outages, Azure DevOps Services limits the resources individuals can consume and the number of requests they can make to certain commands. When these limits are exceeded, subsequent requests may be delayed or blocked.
Most rate limits are reached through REST API calls or non-optimized queries. For more information, see Rate limits and Best practices (to avoid hitting rate limits).
Migrate and import limits
When migrating from on-premises to Azure DevOps Services, you might encounter several size limits, including:
- Database size exceeding the recommended size
- Largest table size exceeding the recommended size
- Database metadata size exceeding the supported size
For more information, see Migrate data from Azure DevOps Server to Azure DevOps Services and Troubleshoot import and migration errors.