Overall Satisfaction with PagerDuty
PagerDuty is being used for on-call teams throughout the organization. When issues arise, whether it be with SQL or the network, alerts are sent to PagerDuty, which are then transmitted to the on-call engineer via an API call. It also houses the on-call schedules and contact numbers for all teams.
- Network outage alerts
- SQL outage Alerts
- Contact tree notification
- Automated escalation
- When getting a phone call, PagerDuty doesn't seem to allow acknowledgments of alerts through the phone, which it says it does. I constantly receive a message that it was updated by another person - when in reality, it wasn't.
- Smarter notifications. If an alert was snoozed for a time, when it comes back, it sends out another alert. It should, I think, send a message asking if the alert is still an issue and give the option to close.
- Make schedule changes more intuitive.
- One button to acknowledge and close an alert.
- If set up correctly on the Network Monitoring side, PagerDuty allows for a HUGE ROI by alerting teams of outages and helping to minimize the impact on the business.
- PagerDuty does require that integrated systems, especially Solarwinds, are set up and administrated well. Poorly created alerts or systems without good parent/child relationships will lead to engineers getting calls on issues that should not require them being woken up at 3 am.
- PagerDuty is great for a single pane of glass solution for issue escalation, contact, and scheduling.
- Third-party integrations. PagerDuty can be easy to integrate (like with Solarwinds) or much more time-consuming (like with Cherwell). So knowing what you want to integrate PagerDuty with is important, and finding out what steps are necessary for integration is key when determining the level of work required.
Our organization, which runs several high-profile online benefits portals, rarely misses an alert from PagerDuty. There are times that we receive notifications from PagerDuty itself of issues on the backend. However, those issues are normally resolved very quickly. Setup for PagerDuty is relatively simple, with the most difficult part being the setup of schedules within the application. While this is not difficult, it can be time-consuming. I consider that a positive aspect as it's something that would have to be dealt with, regardless of the notification system used. PagerDuty has not been available when we need it to be.
We currently use the PagerDuty API integration for SolarWinds. The setup for this was EXTREMELY simple, only requiring a custom property within SolarWinds that contains the API information. However, as stated previously, it does require parent/child device relationships to be done - otherwise, engineers are inundated with alerts in the event of an outage. While the monitoring integration works very well, integration with the various ticketing platforms can be a bit trickier. We use Cherwell, and the integration process there is definitely more involved than that of ServiceNow. So depending on whether or not automated ticket creation is something that is required (like for Sev 1 or 2 incidents), it is something that definitely requires research into.
The PagerDuty phone application is very, very good. In fact, it is the primary access method for most engineers in my company. Our escalation procedures are time-based. If an alert is not acknowledged within set time limits, different processes are invoked. For our team, we have two notifications via pager set before a phone call. If the alert is not acknowledged after the phone call, the escalation process begins.
PagerDuty analytics are not used.
PagerDuty is very similar to xMatters, with only slight differences. The integration with network monitoring tools and the ticketing system is more involved. Instead of simply forwarding an alert from the monitoring tool to the paging service, xMatters requires the creation of an alert with a specific payload. That payload then has custom properties and fields extracted and placed into the ticket that is created. However, when it comes to just alerting engineers of outages, xMatters performs similarly to PagerDuty.
While it is exceedingly rare, whenever an issue has come up with PagerDuty, it has always been quickly addressed by their support team. Furthermore, they are very much aware of what is happening and will often times proactively alert users of issues and notify them when those issues are resolved.
Do you think PagerDuty delivers good value for the price?
Are you happy with PagerDuty's feature set?
Did PagerDuty live up to sales and marketing promises?
Did implementation of PagerDuty go as expected?
Would you buy PagerDuty again?
PagerDuty is great for network alerts. However, it is necessary for parent/child device relationships to be formed correctly. If that is not done, on-call personnel will be flooded with alerts, especially in the event of a power outage or network outage. PagerDuty is also well suited for alerting when critical servers go down or are unreachable. In this scenario where parent/child is less important, PagerDuty really shines in letting the engineers know something is down and providing a single pane of glass for who to contact on other teams, if necessary.