This is awesome! I wish I had something like this back in 2003-2005 when I was one of four people on shared pager duty. Nowadays I just write perfect code ;) (and we have a dedicated and awesome ops team).
A couple suggestions...looking at your prelim pricing page, the prices look good, but I can foresee a problem with the notification system that accidentally sends way too many alerts. How will you accommodate that? It would be nice to have a grace period or some way of saying, ok we realize it was a mistake, we'll let this one slide but the next time you will be bumped up automagically to the appropriate pricing plan.
Also how easy is it to integrate with existing notification tools like Nagios or Cacti? Or is it just tied to email notificatons from those systems? That would be a downside if it's the latter. I've worked at orgs with truly crappy email systems that are down more often than not. Sending an email blast for a production system outage is likely to get it canned by the sysadmins.
Finally how does the phone call alerting work? Is it text-to-voice? Or pre-recorded messages? Is it customizable?
We tried to design PagerDuty to minimize the possibility of message storms. We did this by decoupling the sending of alerts from the reception of triggering emails. Specifically, we don't generate new phone calls or SMSes if an already triggered alarm receives a new triggering email.
As for the pricing plans, we don't plan to bump you to the next plan if you exceed the limits. We have overage prices for each type of message (phone/SMS). So, going slightly over your quota isn't going to cause a really big bump in your fee.
Currently, PagerDuty only integrates with monitoring tools using email. We do have several customers sending their Nagios alerts to us. We are also planning to build a Nagios plugin to better integrate Nagios with our system.
We haven't actually found the email integration to be a big problem so far. What some of our customers do is set up some external network monitoring tool (i.e. Pingdom) to make sure their mail servers are up and running. Those services are in turn hooked up to a PagerDuty alarm so that we can notify the right person if a site's mail server or external connectivity fails.
Phone call alerting is text-to-voice. It tells you which alarm went off, and also reads you the subject of the error. What kind of customization are you thinking of?
I understand the desire to stop message storms, but in my 5 minute use case, I hit that and perceived it as a limitation and it makes it probably not usable for me, as I already have a good monitoring/notification/paging system that I was trying yours out as an additional notification vector. (That might place me squarely out of your target market, in which case you should ignore this feedback. :) )
Let's say I already have an existing monitoring service that sends emails on network events. I might decide to hook in your service and send my network faults there.
I get "port XX on switch YY link state down" and that gets routed through the system. One minute later I get "office of the CEO video conference network down" but pagerduty never sends that to my mobile device because I'm busy looking at the one port down alert.
Yes, I realize there's a technical solution to create multiple pagerduty trigger email addresses, but at a minimum, I'd encourage you to be more clear about that feature/limitation.
Overall comments: several UI elements were "not pretty" looking on IE7, and some of the call to action graphics "Create your first alert now" were bright yellow and rectangular yet not clickable. No deal-breakers, and I was certainly able to quickly get setup and trial alerts coming.
We actually support having the same email address for multiple alarms in the system. We also have regex trigger rules for each alarm, which are based on the subject and/or body of the trigger email. This means that you can set up a single email address, and trigger one alarm if "port XX on switch YY" is down, and trigger a different alarm if the "CEO video conference network" is down.
It might be easier to discuss your requirements over email. My address is alex[at]pagerduty[dot]com.
I was disappointed when I found that you can only trigger an alarm via email from a separate monitoring system. I was expecting that there'd at least be a way to trigger an alarm if an email wasn't sent on schedule.
I halfway expected there to be a portion of Nagios' features built in, at least the ones that make sense for services open on the internet: like ping, socket, and HTTP availability.
I guess your intended focus is to be purely a distribution mechanism for existing alerts -- which isn't very useful for just one person -- especially since I'd have to set up separate offsite monitoring systems to generate the alerts I care most about.
A couple suggestions...looking at your prelim pricing page, the prices look good, but I can foresee a problem with the notification system that accidentally sends way too many alerts. How will you accommodate that? It would be nice to have a grace period or some way of saying, ok we realize it was a mistake, we'll let this one slide but the next time you will be bumped up automagically to the appropriate pricing plan.
Also how easy is it to integrate with existing notification tools like Nagios or Cacti? Or is it just tied to email notificatons from those systems? That would be a downside if it's the latter. I've worked at orgs with truly crappy email systems that are down more often than not. Sending an email blast for a production system outage is likely to get it canned by the sysadmins.
Finally how does the phone call alerting work? Is it text-to-voice? Or pre-recorded messages? Is it customizable?