I can think of two possible issues that typically lead to this behavior.
The first is that your nested set has become corrupted. The nested set is a strategy we currently use to help manage hierarchical data in a flat relational database. You can read more about it, and find a link to the command-line task to rebuild the nested set, here:
It should be noted as well that, in the upcoming 2.6 release, we are also moving away from using nested sets wherever possible, in favor of using the new Common Table Expressions (CTE) available in MySQL 8. This should not only increase performance and scalability, but also reduce the likelihood of this type of issue.
The second likely cause has to do with known issues in the sidebar treeview sort settings.
If you are using the sidebar treeview, I recommend that you make sure your sort options (in Admin > Settings > Treeview) are set to Manual. The identifier and identifier-title options are known to be buggy and I don't actually recommend that anyone use them until someone wants to sponsor a fix (it's more complicated than a simple bug fix, unfortunately), but the issue itself stems from the code trying to sort on identifier values, and what happens when it encounters records with no identifier. Essentially, your treeview can get caught in a weird loop showing the same handful of records over and over! If that happens, change the setting to manual, and have your IT team clear the application cache and restart services. This typically resolves the issue.
This previous thread on the topic says that if all your descriptions in AtoM have both identifiers and titles, then you don't typically see the issue - however, I have since heard reports of users still be affected by the issue even when this is the case. For now, the best workaround is to switch the sort option to Manual.
Our devs have previously provided more information and options for fixing this permanently, but as you'll see, they are not easy fixes, and as such, will require community support (either in the form of code contributions or development sponsorship) for us to be able to address. See:
Keep in mind that these rough estimates were provided two and half years ago, so there may be additional options available, especially with more recent versions of PHP, MySQL, and ES being used in AtoM, and in any case, the code base has changed a lot so we would want to review these numbers anyway and see what updated development solutions might be available, and how much effort we think would be required. However, I would still expect us not to want to implement something like option 1 in the link above (as it would lose functionality), and that any other options would likely still be costly and require community support.
Let us know if these help!