Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: I was frustrated with pricing of PagerDuty et al., so made one myself

allquiet.app

Post reply on HN
Print view View original

61–70 of 135 posts

Re: Show HN: I was frustrated with pricing of PagerDuty et al., so made one myself

#61

Post by amluto »

Can it have a calmer way to deliver notifications? The PagerDuty app goes directly from zero to klaxon, and the klaxons are horrible sounds from a bizarrely limited menu.

Ideally there would be a configurable escalation-to-the-same-user policy. I might want: vibrate-only notification, then normal notification, then critical notification, then phone call, in that order, with configurable delays. Ideally this would interact well with focus/sleep mode, so I could get a calm critical notification before full klaxons.

Other feature request: a way to tell the app to shut up already. I’ve occasionally dealt with an issue causing notifications every minute or so. The last thing I need while fixing it is more notifications to ack or silence.

Re: Show HN: I was frustrated with pricing of PagerDuty et al., so made one myself

#62

Post by mads_quist »

ChrisInEdmonton wrote: post #52

I used PagerDuty for more than a decade at my previous job. I didn't care much for the UI. But you know why PagerDuty does so well? Basically bulletproof reliability. 99% uptime won't cut it. 99.9% uptime won't cut it. You need to be as close as possible to 100% uptime, no excuses. Pagerduty isn't perfect, but it was one of the most reliable services we ever used. I sincerely wish you luck with allquiet. I just want…

That's a very helpful comment. Thanks. I might consider adding SMS / Calls to the notification channels. I didn't look from the perspective that Folks described here.

Regarding Uptime 99.99%. That's very true and also a good hint.

My current stack is very robust - tried and tested in many other products that I worked in.

Some other HN user also suggested to include an uptime status page to create this kind of confidence.

Re: Show HN: I was frustrated with pricing of PagerDuty et al., so made one myself

#63

Post by compumike »

ChrisInEdmonton wrote: post #52

I used PagerDuty for more than a decade at my previous job. I didn't care much for the UI. But you know why PagerDuty does so well? Basically bulletproof reliability. 99% uptime won't cut it. 99.9% uptime won't cut it. You need to be as close as possible to 100% uptime, no excuses. Pagerduty isn't perfect, but it was one of the most reliable services we ever used. I sincerely wish you luck with allquiet. I just want…

Anyone who has done real engineering would realize that this problem a consequence of a design flaw with PagerDuty (or other alternatives with a similar API, where alerting is only triggered directly by a webhook).

If your design requires that the alerting service can receive a one-off affirmative "something's broken" packet, then yes, you are asking an inherently unreliable distributed system (i.e. the Internet!) to reliably deliver a critical message at a time when you know something is broken. Good luck. :)

Instead, if you use something like a periodic heartbeat (also known as a dead man's switch, inbound liveness monitor, or outbound HTTP probe -- all of which we support at Heii On-Call https://heiioncall.com/ out of the box), you can tolerate some occasional lost messages, regardless of whose end they are on.

Real reliable systems (for example, embedded systems) use periodic heartbeats and watchdogs, and are usually designed to be lenient to the occasional missed heartbeat. If the system being monitored is truly down, then enough consecutive heartbeats will be missed that some threshold is reached and the on-call person can be alerted (or a watchdog timer can reboot a system, etc).

Re: Show HN: I was frustrated with pricing of PagerDuty et al., so made one myself

#64

Post by mads_quist »

mdaniel wrote: post #33

I'm surprised to see you used Mongo ( https://github.com/AllQuietApp/MongoQueueing#what-about-rabb... ) after all the replies in this thread citing "delivery reliability" What did you find that made NoSQL a good fit for tracking incidents and escalations?

Good Point, MongoDB supports multi document ACID transactions for more than 5 years now.

Re: Show HN: I was frustrated with pricing of PagerDuty et al., so made one myself

#65

Post by ginkgotree »

Bravo. PagerDuty is long overdue to be replaced by a better service. Their pricing is exorbitant, and their sales / account team forces you into year long contracts to buy seats you don't need. We are currently being threatened with an $8k bill because they claim we didn't "cancel renewal" in time.

Re: Show HN: I was frustrated with pricing of PagerDuty et al., so made one myself

#67

Post by mLuby »

SanderNL wrote: post #41
mLuby wrote: post #11

Why is the pricing per user? Is that what your costs are most dependent on? I bet not. I'd argue $5/user is just teaser pricing on its way to PagerDuty's $21+/user. Regardless, cool project—happy to see more competition.

You base your salary solely on living expenses?

My employer sure does. Unless you're telling me that devs in major US cities are actually 2x better than rural US coders, who in turn are multiple times better than devs in poorer countries.

Re: Show HN: I was frustrated with pricing of PagerDuty et al., so made one myself

#68

Post by lokar »

compumike wrote: post #63
ChrisInEdmonton wrote: post #52

I used PagerDuty for more than a decade at my previous job. I didn't care much for the UI. But you know why PagerDuty does so well? Basically bulletproof reliability. 99% uptime won't cut it. 99.9% uptime won't cut it. You need to be as close as possible to 100% uptime, no excuses. Pagerduty isn't perfect, but it was one of the most reliable services we ever used. I sincerely wish you luck with allquiet. I just want…

Anyone who has done real engineering would realize that this problem a consequence of a design flaw with PagerDuty (or other alternatives with a similar API, where alerting is only triggered directly by a webhook). If your design requires that the alerting service can receive a one-off affirmative "something's broken" packet, then yes, you are asking an inherently unreliable distributed system (i.e. the Internet!) to…

Also, the system at google is not in the path of the first page (that is direct from the alert infra), the more complex system is only needed for escalation.

Re: Show HN: I was frustrated with pricing of PagerDuty et al., so made one myself

#69

Post by mads_quist »

mcsniff wrote: post #38

I would recommend running through your docs with a native english speaker. Congratulations on the launch! Be proud of what you've put together here, and looks to be all by yourself too? The infra for a site, backend, and polished mobile apps for both platforms on your own. From another "I'm doing it all myself" dude, very well done!

Thanks for pointing out to go through the docs section. Appreciate it.

Re: Show HN: I was frustrated with pricing of PagerDuty et al., so made one myself

#70

Post by jedberg »

The main problem that Pagerduty solved at the time was deliverability of alerts. It was hard, and still is, to solve the problem of making sure the right people actually get the alerts. It was so expensive because they have redundant hardware all over the place with different providers, and they ran it all themselves, including SMS and phone gateways.

One of their key differentiators was that they were not built on AWS, so when AWS had an outage, you still knew about it. That also made it expensive.

With Pagerduty, you're mostly paying for reliability. The peace of mind knowing that someone will get notified when there is an outage.

This looks interesting, but from your page I'm not sure how you're better than Pagerduty.

App only notifications looks like a disadvantage to me. What if push notifications are down? What if I'm on DND?

Where is your infrastructure built? Is it on a cloud provider? What happens if that provider has an outage? If you want to build a PD competitor you have to build it on your own hardware in multiple datacenters owned by different people with different interconnects. If you haven't done that how will you stay up when your customer's provider goes down so that they know about it?

Post reply on HN