This depends entirely on the org. In many places with lots of engineers a broken build means hundreds of people are blocked n their work, it's bad news, lost pr

This depends entirely on the org. In many places with lots of engineers a broken build means hundreds of people are blocked n their work, it's bad news, lost productivity, slipped schedules, it's legitimately a high priority (page someone to fix this) issue. But that's not always true, especially at smaller dev shops. However, smaller shops sometimes like to imitate the big corporations, it makes them feel more important, even though it's not necessary. In both cases having broken builds in your production pipeline are an indication of a process or policy problem more than anything else, especially in 2018 when build hardware is cheap and CI platforms are everywhere. (P.S. I've worked in both types of orgs. Ones where the builds had several teams of people working on them, where broken builds could mean huge amounts of lost or blocked work hour by hour and fixing builds was a very high priority task, and where there were huge systems and extensive policies designed to forestall build breaks getting checked into important branches. All of those systems and policies were built out of a history of chaos, where builds were almost always broken (if you have thousands of devs, and none of them take build breaks seriously, then there will almost always be one break checked in every day), schedules were unreliable, etc. So much so that it was burning people out. On the other hand I've also worked in places where a build break can be handled by filing a bug and letting it go through the normal process of triage and fix over a period of many days. Which process is appropriate is entirely dependent on context.)