New tooling often has a great initial idea, but due to poor execution or architecture, it quickly turns into spaghetti code that is un-maintainable and prone to bugs. If design and implementation are kept to high standards, you can have a better assurance that you will not get unexpected breakages or at least that the bugs can be easier to find and fix. The competency of the core project developers plays a huge part in this aspect and since most of the newer tooling is open-source, taking a look at the codebase can often be very helpful in this respect.

It is near impossible to put exact guidelines for evaluating projects that span all sorts of technologies and systems, but there are some red flags that should be treated as warning signs of potential troubles in the future for the tooling that is used in critical applications:

• Lack of tests: Without tests, assurance that the code works is pretty much eliminated and you are hoping that the developer making changes was careful enough when implementing new features and that they did not break current functionality. I have only seen a handful of developers in my life that can be as mindful of all the edge cases as a test harness, but I would not hold my breath that the project you are looking into has one of them.
• Clever code: From time to time, a project will have one or more developers that are more concerned about showing their skills off than the maintainability of the project they are working on and they will almost always turn files they touch into code that only they can work on, causing future problems with adding features or fixing bugs. Almost always this type of change is one-directional and after a long enough period of time it usually ends up in the death of the project (more often than not in my experience).
• A high count of critical bugs open for extended periods of time: For any project, there will come a time where you will encounter a critical bug that must be fixed as soon as possible, and by seeing trends in how long fixes take, you can see whether the team is capable of quickly fixing an issue or whether it pays attention to the wider community. While more of a subjective metric, it becomes extremely important as the profile or security posture of your service increases.

You can also use any other metrics for evaluation such as: old and un-merged pull requests, arbitrarily closed bug reports, and many more as long as you get the right notion of the codebase's quality. With that knowledge in hand, you can properly evaluate what the future might hold for your candidate tooling and how your infrastructure can evolve with it.