There are some scenarios where you may expect to receive a notification, but the criteria for sending a notification were not met. It is expected behavior that you would not receive notifications in these cases. Some of these situations are outlined in the sections below.

Supported Countries

PagerDuty can send notifications to many, but not all, countries around the world. Please see Supported Countries to confirm whether PagerDuty supports notifications to your region.

SMS Responses: Even if PagerDuty can send SMS notifications to your country, SMS responses may not be supported. Please see the section SMS Notifications to confirm whether SMS responses are supported.

Service Settings

Depending on how your services are configured, if may be expected that incidents do not trigger. You can read more information on the following sections in Configurable Service Settings.

• Service is Disabled or in Maintenance Mode: If a service is disabled or in maintenance mode, incidents will not trigger. As a result, incident notifications, including push notifications, will not go out.
• Support Hours: If the service has support hours enabled, then PagerDuty will send incident notifications according to these settings. Support hours settings will determine how incidents are triggered during and outside of support hours.
• Notification Settings: A service's default notification urgency may not align with the notification urgency you were expecting. For example:
  • High-urgency incidents triggered on the service will override low-urgency service settings.
  • If high-urgency notifications are the default for the service, then you will be notified according to your high-urgency notification rules. Your low-urgency notification rules would not apply to incidents triggered on this service.
• Alert Grouping: With alert grouping enabled, alerts will group into an open incident to reduce notification noise. You will not receive a separate notification for subsequent alerts that group into the open incident.
• Acknowledgement Timeout: With the acknowledgement timeout feature enabled, an acknowledged incident will re-trigger after a specified amount of time. When the incident re-triggers, it re-notifies assigned responders and, if on-call responsibilities have rotated since the incident triggered, the current on-call user, too.
• Auto-Resolution: With the auto-resolution feature enabled, incidents triggered on the service will automatically resolve after a given amount of time, thus halting any further notifications from being delivered.

Notification Rules

When an incident triggers and is assigned to you, PagerDuty will notify you depending how you have configured notification rules in your User Profile. If you are not receiving notifications as expected, please check the following items to confirm your notification rules are configured correctly:

• Notification Rules: Navigate to User Profile Notification Rules tab, and confirm that your notification rules match the expected behavior.
• Notification Timing: Staggering your notification rules can help with delays that sometimes occur when a large volume of notifications are delivered at once.

Incident Assignment Notifications

On-call responders can expect to receive notifications when an incident is assigned to them. In addition to the following points, the sections Escalation Targets and Notification Behavior contain additional details about how PagerDuty determines who is on-call (i.e., who to notify) when an incident triggers.

• Check That You Were On Call: Check the user and schedule targets in the services' escalation policy, to determine who was on call at the time the incident triggered.
• Check the Escalation Policy: Verify that the impacted service is associated with the correct escalation policy, and that the appropriate schedule(s) are associated with that escalation policy.
• No One was On Call: Incidents will not trigger on a service during times when no one is on call.
• Check the Escalation Path: Review the incident timeline to confirm if the incident was resolved or acknowledged before it would have escalated to you.
• Inbound Events: The event may not have made it through to PagerDuty, or there may have been an issue with the payload header/body. Review the Alerts Table to confirm if there are any alerts associated to the event.
• Acknowledge/Resolve: PagerDuty will not send incident notifications while an incident is in the acknowledged or resolved state. Find the acknowledge and resolve timestamps, and compare the timestamps to the notification delivery timing configured in your Notification Rules. The incident may have been acknowledged or resolved before the notification was scheduled for delivery.
• Event Orchestration: If an inbound event matches a Suppress incident and notifications condition set in a global or service orchestration, no notifications will go out.
• Snooze/Suspend: Review the incident timeline to confirm if the incident was snoozed or suspended at the time you were expecting the incident notification.

Responder Notifications

When a user is added as a Responder to an incident, they will receive notifications about the request.

• Responders List: Check the Responders section on the incident page, to verify if you were requested as a Responder, or included in the escalation policy that was requested as a Responder.
• Requesting an Escalation Policy: A Responder from the escalation policy may have already joined the incident, which halts Responder requests from being sent to users on higher levels of the escalation policy.
• Incident Resolved: Review the incident timeline, to confirm if the incident was resolved before the Responder request would have escalated to you.
• High Urgency Notification Rules: Responder requests are sent in accordance with your high-urgency notification rules. Low-urgency notification rules do not apply to Responder notifications.

Stakeholder Notifications

Please read more information about the points listed below in Communicate with Stakeholders.

• Subscribe to an Incident: To confirm that you are subscribed to an incident, on an incident's details page navigate to the Status Updates tab Manage Subscribers and scroll to the Subscribers section.
• Post a Status Update: Stakeholders will receive a subscriber notification when a status update is published. Check an incident's Status Updates tab or the incident timeline, to confirm which status updates, if any, you should have received.
• Status Updates vs. Incident Assignment : Stakeholders do not receive notifications when a user is assigned to an incident.
• Multiple Subscriptions: Review an incident's Subscribers section to check if you appear in the list more than once. This may cause the same status update to be delivered to you multiple times, or cause notification deliverability issues/delays which will impact your ability to receive the status updates.

On-Call Handoff Notifications

PagerDuty can send On-Call Handoff Notifications (OCHONs) when a user is about to go on or off call. Please read On Call Handoff Notification Settings for more information.

• Check the Schedule: Check the schedule, to confirm that you are scheduled to go on call.
• Check the Escalation Policy: Check that the schedule is associated to an escalation policy, then verify that the escalation policy is associated to an enabled service.
• Requirements:
  • You must have on-call handoff notifications configured in your User Profile.
  • You must be a target on an escalation policy, either as a user in the escalation policy, or on a schedule in the escalation policy.
  • The escalation policy must either have OCHONs enabled always or be in use by a service that is not in a disabled state.
• Restrictions:
  • PagerDuty only sends on-call handoff notifications via SMS, push notification, and email.
  • PagerDuty can only send on-call handoff notifications up to 48 hours in advance of a user going on or off call.