I'd like to add a me too comment, but with another thought about historical build health. It's not that I don't find it useful, but I'd rather see it along with my other metrics rather than included in the UI of my CI tool. If Jenkins could be used as a Grafana source or were able to export build metrics to Influx/Prometheus, people could use existing tooling/dashboards to display build health over time while keeping the main Jenkins UI clean and focused on the current state of the builds.

Also, and I apologize if this is no longer how the Jenkins weather indicators work, but the last time I used Jenkins, the weather indicators were based on the number of failed builds, not the time the build wasn't green. For me, the number of failed builds is far less interesting than the amount of time that the build was failing. If a developer scrambles with three checkins in 15 minutes that attempt to fix the build and the third one succeeds, that's a better situation than a developer who takes a more measured approach that fixes the build four hours later on the first checkin. The first developer might have created a slightly messier commit history, but the second developer blocked the entire team for half a day. Taking the view that historical build information is really time series data would, to me, be much more insightful.

You can expose some metrics via https://wiki.jenkins-ci.org/display/JENKINS/Metrics+Plugin but not the per job success and failure counters you'd need to build what you suggest. That would make a good addition.

Team members should have sandbox builds available. Its maybe not true that the integration build is blocking everybody. I don't think this statistic is worthwhile. Just knowing its broken, and making steady progress on integrating a working system, is often enough.

Curious why you need sandbox builds if you've got builds per branch?