At the end of the day, everyone important is on some kind of defacto on-call (you don't think the head of sales will be woken up for the #1 customer, or the whole marketing team won't be pulled in on a Sunday if there's a big negative story in the NYT?).
A major benefit of PagerDuty is making it explicit how much you're burdening a specific on-call person or team. Some of the new stuff around team health is a great way to show managers "hey, we're pushing unfinished code that's ruining my team's work-life balance, we need to fix our procedures"
(Disclaimer: former PD employee, was on-call for years & learned how to police my work life balance pretty well)
I get that things happen, even when i made minimum wage and stocked shelves I got asked to work when I wasn't scheduled for an atypical situation.
I guess there's a difference between some once a year oh shit moment and every six weeks planning my life around being close to a computer, phone and an internet connection.
The company I work for makes and supports bespoke software for a wide range of clients, employing roughly 30 people. We are open from 9-5 and by default provide no support outside those hours. The only exceptions are incidental, well communicated and seen as a logical part of our jobs (for example, a big coordinated release of a new application in the weekend outside business hours).
We host 95% of the applications that we create at our sister company which exclusively does hosting where there is an on-call system, but it is only available to their largest customers and only by request. Of course company-wide alerts (an entire router that goes down, degraded storage, etc.) do garner an on-call response.
I worked for a state agency that hosted a data archive and real-time collection of hydrology data. It was not considered "mission critical", and as such there was no on-call.
It was pretty cool, since they practiced 8-hr work days. My only issue was that they were way more focused on ass-in-chair time than productive time, and weren't flexible. At that time, I commuted via bus, and it wasn't uncommon for the bus to be delayed by 15-30 minutes if there were traffic incidents along the route. I wasn't allowed to clock in early if my bus arrived early, and was penalized and documented if the bus was late. So there wasn't a chance in hell I was going to catch the earlier route and arrive 45 minutes before my shift, but they sure were pissy when that bus was late.
I knew a guy who worked for the local rail transit despots. He used to take their service into work until they told him he had to stop being late and that delays in their own service was not an excuse. At least they weren't in denial about their quality of service.
My passive-aggressive response when faced with something like that was along the lines of "If it's so important that my butt be in the seat at 8 on the dot, then it's equally important that it be walking out the door at 5 on the dot."
Since at the time I was coding in a hallway-facing cube in a cubicle farm, after-hours was my best time to be able to get into "flow" and really get things accomplished without interruption.
After years of being on on-call rotations, including while working at Pager Duty themselves, I am now on a web development team with no pager rotation and no use of paging whatsoever. It all depends on the problem domain you are in, and how the company you work for thinks about supporting and operating their software.
"Software" might be a bit too broad a brush?
Embedded development, or stuff that ships and runs on customer premise don't tend to involve oncall, while SaaS or internal services are more likely to.
