Work Item Revision Limits

Dan Hellem

Every time a work item is updated, it creates an entry in the work item history. This is a great feature for users to track all the individual changes made to work items. However, we have seen organizations with automated tools that will generate tens of thousands of work item revisions. It creates issues with performance and usability on the work item form and other REST APIs. As a result, we are implementing a work item revision limit of 10,000 to the Azure DevOps Service. This limit is to prevent automated tools from running amok and creating these performance problems.

How the revision limit works

Once the number of revisions reaches 10,000, the work item can no longer be updated through the REST API. Work Items Update is the API most affected by this change.

As a result, the API will return a status code 500 with the following exception message:

Work item {0} has {1} revisions, but currently, when updating via the API, only work items with up to 10,000 revisions are supported.

What about manual updates?

This revision limit only affects the REST API. Even after the work item reaches 10,000 revisions, Manual updates are still permitted through the web interface.

Fix your tooling

If you have tooling in place that is using the Work Item Update REST API, you should be checking the response and adjusting accordingly. For example, say your tooling is iterating through a set of work items and doing updates, and you reach work item that has over 10,000 revisions, you should:

  1. Catch the exception
  2. Mark the work item to ignore further update attempts
  3. Log the event
  4. Abandon the current update
  5. Manually open the work item to determine if it can be closed, deleted, or removed


As you can imagine, a work item with 10,000+ entries in the history are going to cause performance and usability issues. Not only with the History tab on the form, but with other REST API endpoints like the Reporting Work Item Revisions. We think 10,000 is very reasonable limit for the majority of our customers. If this limit might be a cause for concern, please let us know.


Your friends in Azure Boards


Discussion is closed. Login to edit/delete existing comments.

  • Ben Reisner 1

    A great feature would be to allow a flag on the REST API to not leave an entry in the work item history, and not modify the Change Date. Although my organization would never approach 10,000 updates via the REST API, we do make some updates. We have some queries that sort by the Change Date to show us what developers are actively working on, and this gets thrown off when our automated tools update the work items.

    • Dan HellemMicrosoft employee 0

      I like it! 🥰

Feedback usabilla icon