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.