Disclaimer: I work at http://www.pagerduty.com http://www.pagerduty.com so feel free to tar and feather accordingly. Carrying the duty pager is a painful exper

Disclaimer: I work at http://www.pagerduty.com http://www.pagerduty.com so feel free to tar and feather accordingly. Carrying the duty pager is a painful experience for some fraction of companies, BUT the long term trends are promising. Here's what I'd keep an eye out for (I've been on call for ~5 years): * Does being on call affect your other commitments? At PD we scale back the number of predicted story points by ~50 for the devs that are on call. * Are you empowered to permanently fix the root cause of whatever woke you up? (that's where that 50% of time goes) If you aren't, that's a big red flag. Not all developers take advantage of it, but the ones that do are much happier once they kill the root cause with fire. * Are you compensated for on call? Among our customers, we have a few that pay $500/week for on call duty, that seems to be the rate at which you can easily find people to swap shifts with. * Make sure you are off call sometimes. Seriously. * Who owns the pain report? Someone needs to track how often (and when) people are disturbed and make sure that you are making progress as a team (Github's Ops team is amazingly good at this). If the house is always on fire, you're not a firefighter, you're a person who lives in a flaming house. * Is it a NOC model, where you can write down common things to try to solve a type of problem (and then you're only paged as an exception) or are you paged for everything? (That's a severe over simplification) * What is the expected response time? What is the required response time? * How are you onboarded? The worst time ever to fix a problem is alone, with no context, while things are broken at 2am. That's off the top of my head; there's good advice in this thread. if you're still lost though, feel free to reach out to me: dave@pagerduty.com