[gnaman]

>If your expected response time is of the order of 5 minutes, then you are not "on-call", you are working 12 hour days

I'm a new dev at a fairly young startup. We have recently started an oncall process and we have similar response times for oncall though our workload isn't nearly as heavy since our scale is low. What's the standard in oncall response times/expectations?

[PapaSpaceDelta]

I don't think there's any real standard, since it very much depends on application SLAs, industry sector, size of the on-call team, geographic location, length of on-call rotation, frequency of call-out, how realistic the management are, how much inconvenience the team members are willing to put up with, etc.

For example, I work in London and it would be unreasonable to expect that someone could travel between home and work on public transport and still meet a response SLA less than one hour. That would likely be a different length of time in another location, or if people worked 100% remotely, for example.

My opinion is that if you have a response time less than say 30 minutes, then you actually need to be compensating people for sitting in front of their computers ready to respond immediately, whether that be in the office or remotely.

Unless call-outs are very frequent (in which case there are underlying reliability, capacity management, and/or alerting issues which need to be resolved), then on-call isn't really about the extra time spent working, but the restrictions on what one can do whilst on-call.

To use a fairly simple metric: if an on-call SLA means that I have to be concerned about whether I can pop out to a local shop or how long I can spend in the shower, then I don't think that I would be on-call, I would be working.

Of course start up environments (especially early stage) are always different from more corporate environments and there are generally greater resource constraints in general. For a start up I am usually looking more at what valuable experience I can gain, rather than maximising remuneration (subject to a certain base-level of course).

However ultimately the question remains the same: do I think that what I am getting out of this role is worth what I have to put into it? There are probably roles in which I'd be willing to put up with the inconvenience of very short on-call SLAs, because either they paid very well, or I was gaining very valuable experience.

Whether a role fulfils ones own expectations for the reward/expenditure ratio is a question that everyone has to decide for themselves.