Hacker News Reader

Comment by arupchak | Hacker News Reader

This is a great tool. I really like the idea of parsing the email address for what type of alarm to use. That makes this straight-forward while at the same time making it incredibly easy to integrate with any existing alarming system.

The reply via SMS feature is excellent and something that I always want in any monitoring system.

I'm curious about the security around the email alerts, can anyone send to the specific trigger-alarm@mysite.pagerduty.com or can you add at least a 'FROM:' check?

You probably have this on your road-map, but if a ticketing/worklog system could be integrated with this, you could add an incredible amount of value for folks working on the problem in real time.

View on HN

This is a good point... the first step is getting ahold of the right person, but after that there will probably need to be some sort of dialog or coordination as the on-call person tries to gather more data about the issue, reproduce the problem, tests the fix, etc. Providing that sort of system would certainly be very useful for your customers.

Overall great idea with PagerDuty though, especially if one's business relies (survives) on their website's/system's uptime. Reducing MTBF is often very hard, especially after a certain point, and reducing MTTR is therefore very important for improving availability.

Integration with a ticketing system is a great idea. We are thinking of adding support for Lighthouse, so you can coordinate, document and work with other people on resolving triggered alarms.

We don't have a FROM check at the moment. I'm not sure how helpful this would be, since it can be arbitrarily spoofed by an attacker.

The email addresses for alarms are editable; if you get spam to one of these addresses, you can change the address. We were also thinking of adding an option to obscure the email address by adding a uid to the end. An example would be trigger-my-alarm-5j3rt@acme.pagerduty.com.

We also offer regex-based filters on both the subject and the body, so you can configure an alarm to only trigger if a certain keyword appears in the message.

I like the uid idea or even having a unique passphrase in the subject of the email.

Granted, I'm thinking of monitoring systems on a much larger scale where even a single instance of spamming can keep the entire dev team up at night. I do not see this being a problem for the smaller targeted audience that you are going after that will initially only set up a handful of alarms.

i would not use a uid tied to the users account as a security precaution. never lend out more info than you need to. i would make it an user defined string.

Reply on news.ycombinator.com