Since we launched our Multi-User Alerting feature last week we’ve received a lot of good feedback and have seen high adoption across the board. Multi-User Alerting was our most requested feature and we wanted to make sure we got it right while maintaining our reliability standards. We’ve made significant changes to our architecture and workflow to lay the foundation for future alerting use cases.

Coming Up With a Plan

The biggest challenge we faced was the need to restructure our alerting data model to assign incidents to multiple users and allow multiple users to acknowledge incidents. We had do this restructuring while keeping everything running for our customers (i.e. we don’t have the concept of service downtime at PagerDuty). Our Product Team documented how they wanted PagerDuty to change and worked together with the our Realtime Team and our Web Team to create a rollout schedule. Although the changes that we were making were big, we came up with an release plan so that each piece of the rollout was incremental and backwards compatible.

Keeping Track of Multi-Acks and Ack Timeouts

With Multi-User Alerting, incidents are assigned to multiple users, and can be acknowledged by multiple users. Multi-acks help teams gather information around incident responsiveness – you can find out who rises to the occasion and who sleeps through their alerts. Since incidents now can be assigned to and acknowledged by more than one user we had to add new tables to our database to keep track of that information.

Incidents are associated with services and within each service the team can set what the incident acknowledgment timeout should be. Incident ack timeouts cause the incident to return to the Triggered state, and prevent incidents from being forgotten so services that are highly critical are configured with shorter timeouts.The timeout is relative to when the incident was first acknowledged, and with multiple acknowledgements, the timeout will be reset every time the incident is re-acked. For example if the incident ack timeout is set at 5 minutes and User A acks an incident at 2:00 AM and User B acks the same incident at 2:04 AM, the incident ack timeout would cause the incident to return to the Triggered state at 2:09 AM rather than 2:05 AM. This prevents Users A and B from receiving another alert just 1 minute after User B acknowledged it. We added this behavior to prevent people from being bogged down with alerts for acknowledged incidents that they are actively fixing.

Incident Snapshots for Minute Zero Alert Guarantee

The PagerDuty alerting pipeline was built to send alerts that contained incident information that is as up-to-date as possible. If a user has only one notification rule with a 1 minute delay and an incident is resolved 30 seconds after it is triggered, we won’t send the user another alert because it has already been resolved. One consequence of Multi-user Alerting is that it introduced the possibility that one user on an escalation policy could acknowledge/resolve/re-assign an incident before another user was notified about it.

To deal with this wrinkle we modified our pipeline to implement special “minute zero” behavior. If a user has a notification rule set-up with a zero-minute delay, we infer that they want to be notified about an incident in all cases. Even if the incident gets modified in short period between when it was triggered and when the notification goes out, the notification will still go out. For example, if User A and User B are on the same escalation level with an immediate notification rule, and User A acknowledges an incident immediately after it was triggered, it will not prevent an alert from going out to User B.

Time Between Escalation Levels

One workaround that PagerDuty customers were using before Multi-User Alerting was to add escalation rules to an escalation policy that were separated by a very low escalation delay (e.g. 1 minute) – effectively alerting a bunch of users within a short time period. With Multi-User Alerting, this workaround is no longer required, and we encourage any customers who were using this workaround to reconfigure their escalation policies: you can now add up to 10 escalation targets (users or schedules) to an escalation level.

Multi-User Alerting has expanded alerting scenarios for our customers so they can reach the right people who need to know at the right time. Are there alerting scenarios you want to address but can’t? Let us know in the comments.