Browsing through our UserVoice feature requests is a pretty humbling experience for all of us working on PagerDuty.  It seems that as far as we’ve come with PagerDuty in our first year, we have at least another ten years of work ahead!

We’re just putting the finishing touches on the Nagios integration API now.  We’re going to have the first version of this out in the next two weeks or so.  But in the mean time, we thought we should show you all some of the other smaller features we’ve recently launched.

Looping on Escalation Chains

Up until now, incidents ran exactly once through their escalation policies.  Thus, unanswered incidents remained assigned to the last person on the escalation chain. Needless to say, this caused some problems if an alert made it through the escalation process without anyone taking action.

To ensure that open incidents are always dealt with, the final rule of an escalation policy can now direct PagerDuty to reassign the incident to the first person in the chain, and begin the escalation process anew.

We’re especially curious if anyone needs additional flexibility in the escalation policies.  Would the ability to loop back to a rule other than the first be useful to anyone?

Better Regex Support

We’ve made it possible to specify both “AND” and “OR” trigger message regex filters.  We’ve also added the option to filter incoming messages based on the “from” address.  If you’ve ever accidentally hit “reply-all” on a trigger message you’ve been CC’ed, you’ll know exactly why we’ve added the from filter option.

SSL & TLS

Our customers often find themselves needing to log into their PagerDuty accounts while on open WiFi points at airports, coffee shops, and the like.  Up until now, this was sort of a dicey proposition, since only the PagerDuty login and billing pages were SSL protected.  By popular request, we’ve added the option to enable SSL across your entire PagerDuty account.  To enable this option, get your account owner to visit the “Account Settings” page and flip on the SSL option.

By the way, we’ve also configured our mail servers to accept TLS protected SMTP sessions… perfect in case you suspect your network operator or upstream provider has some BOFH tendencies.  Simply configure your outbound mail servers to use TLS opportunistically, and you should be all set.  If you’d like to check to see if your mail is being received encrypted at our end, click “View Email” on an incident trigger and then use the “View Raw Message” link.  If the message is encrypted, the last hop listed in the receive headers will mention a TLS-enabled connection.