Live data from Hacker News

PagerDuty (YC S10) Makes Sure Your Team Knows When A Server Goes Down

techcrunch.com

51–54 of 54 posts

Re: PagerDuty (YC S10) Makes Sure Your Team Knows When A Server Goes Down

#51
post #12

Earlier quoted context omitted.

It seems like more companies are moving from the freemium model to the free trial model. We recently switched over for http://www.theweddinglens.com/ and have been pleased with the increased number of conversions.

Interesting. Why did you make the switch? I'd love to hear details about that. My thinking is that if more people are using the service, that also doubles as an advertisement if the users tell some of their friends, recommend to coworkers etc.

Just because someone signs up for a free service doesn't mean they're going to use and spread it. When you get them committed through paying, then there's an even higher usage rate as they figure out the best way to maximize it.

Under the original free plans we saw a lot of people just signing up for free to play around with it, only to end up paying a couple weeks later. By making it an actual free trial system, we're able to put a lot more pressure and messaging throughout the upgrade process.

Re: PagerDuty (YC S10) Makes Sure Your Team Knows When A Server Goes Down

#52
post #34

Earlier quoted context omitted.

you know what I want? I want some sort of arm band to put my cellphone (or, better, a giant bluetooth vibrator) so that when I sleep, I can be woken by my pager without waking other people who may also be in the bed.

Here you go: http://www.thinkgeek.com/gadgets/cellphone/9e31/

Ooh, thanks! that looks like it might solve my problem.

Re: PagerDuty (YC S10) Makes Sure Your Team Knows When A Server Goes Down

#53
post #33

Earlier quoted context omitted.

SLAs with exceptions based on "fault" are meaningless. Either you guarantee you will keep your shit working, or you don't. (Either way is fine, really... but arguing over "fault" is not a productive activity.)

It's not meaningless? If "working" is dependent on several pieces working, and only some of them is under your control, you can be in a state of "not working" without being at fault. I've had a server go down for a large group of users because of a malconfigured routing table between them and the server. If we'd had an expensive SLA, there would have been significant "what the heck is it we're paying for, then?" disc…

right. my point is that if you are selling the customer a service, and you say 'I will get you network connectivity' and then, for reasons outside your control, you don't get them network connectivity, it doesn't make much difference to the customer if the network is broken because you did something dumb or if the network is broken you are getting DDos'd from china. the point is that the network is broken.

last month I paid out almost fourteen grand in SLA credits because I didn't stop a DDos within my allowed 0.5% downtime. Was it my fault I got DDos'd? no. However, i was the only one in a position to do something about it. (and really, if I wasn't tired and generally an idiot, we would have been down for an hour rather than 8.)

You do need clear lines, though. if you need connectivity from point A to point B, that's easy, I can guarantee that. But defining connectivity to 'the internet' is harder. there are cases where I've got good connectivity to most places, but you can't get to some ISP in dallas, because they've hoarked up the routing table.

Right now, I play that sort of thing by ear. If only one customer is having the problem, I try to figure out where it is and if I can't figure it out, it's not that big of a deal to give them a credit. If many customers are having the problem, well, then I have a problem, and really, it's my job to figure out where that problem is and to work around it... even if that problem is a misconfigured router at some other ISP. I mean, really, what is the customer going to do about that sort of thing?

this is the point of having a SLA; it aligns the interests of the service provider with the interests of the customer.

Re: PagerDuty (YC S10) Makes Sure Your Team Knows When A Server Goes Down

#54
post #33

Earlier quoted context omitted.

SLAs with exceptions based on "fault" are meaningless. Either you guarantee you will keep your shit working, or you don't. (Either way is fine, really... but arguing over "fault" is not a productive activity.)

It's not meaningless? If "working" is dependent on several pieces working, and only some of them is under your control, you can be in a state of "not working" without being at fault. I've had a server go down for a large group of users because of a malconfigured routing table between them and the server. If we'd had an expensive SLA, there would have been significant "what the heck is it we're paying for, then?" disc…

[deleted]
Post reply on HN