The De-Facto Standard
August 01, 2018
The De-Facto Standard
Score 9 out of 10
Overall Satisfaction with PagerDuty
We use PagerDuty to alert engineers when our users are experiencing degraded service or service outages. It is used by the engineering and product teams. For critical issues, the teams that own the affected services are notified first. Unacknowledged alerts are escalated to other members of the engineering team.
- PagerDuty has simple integrations for many of the other services we use, including AWS and New Relic.
- It is easy to manage on-call schedules, alert poliices and contact information.
- PagerDuty is reliable; we've never experienced downtime.
- The interface for switching on-call shifts could be easier to use.
- The positive impact is clear. Alerting is essential; we cannot wait to hear from our users to learn of problems. Building reliable alerting systems is not trivial. Delegating this work to PagerDuty allows engineers to focus on our product.
30 - Engineers, data scientists and product managers use PagerDuty. The engineers and product manager who own the feature or service are the first to be notified. The head of engineering and CTO are the last on the escalation policy.
10 - After the initial policies and integrations are configured, little on-going management is required. Most engineers are capable of configuring new integrations when the need arises. One devops engineer created the initial integrations.
- Alerting engineers and product managers when the user experience is degraded.
- Alerting engineers when thresholds for maintenance are exceeded.
- Helping engineers and product managers understand who is on-call and who to contact.
- The inclusion of product managers in our escalation policies might be somewhat unusual. Otherwise, we use PagerDuty in a narrow, predictable way.
The UI is more complex than I would like. Part of the challenge is that most users use PagerDuty infrequently; I don't remember how I changed a policy last time. Another part of the challenge is that some users expect alerting to be a trivial feature, and are reluctant to invest any time in reading the documentation.
Technical support not required
Feel confident using
Difficult to use
Slow to learn
Lots to learn
- It is easy to acknowledge and resolve alerts.
- It is easy to understand who is on-call, and when they are on-call.
- It is easy to integrate with many, but not all, of the products and services we use.
- Some services require an API integration that is confusing to configure.
- One-off changes to the on-call schedule are confusing to configure. Most users don't make these changes often enough to remember how the next time they need to.
Yes - The mobile interface is adequate for viewing, acknowledging and resolving alerts. It would not be suitable for configuring alerting policies or integrations. Most of the limitations of the mobile interface are acceptable because users will require a desktop experience for the other tools they are using.