Hey @maikel penz, it’s good to have you here!
You can try the following approaches, to automatically raise the urgency to high during support hours without the need to create two separate services:
-
Create a Custom Event Transformer: Set up a custom event transformer that triggers when entering support hours. This transformer should modify the incident’s urgency to high. PagerDuty’s Event Rules allow you to define conditions and actions based on specific criteria.
-
Use Schedules: Leverage PagerDuty schedules to define your support hours. You can create schedules that represent your support hours and associate them with the appropriate escalation policies. During the on-call shift within these schedules, incidents will automatically be escalated based on the severity.
Let us know how this set up goes!
Was this helpful?
Hi @maikel penz!
Just adding my 2 cents to what @xenda amici already replied. When you enable ‘Dynamic Notifications based on alert severity’ the incident urgency is decided based on the mapping below.
If you have high urgency incidents then you can not increase its urgency has its already high. But I see your point and we will reach out to the product team and share your feedback.
To overcome this limitation you can use our REST APIs and create a recurrent task that runs when the working hours shift start and checks for unacknowledged incidents with low urgency and increases their urgency to high.
Just one question, why would want to increase the urgency of all incidents to high in the first place? To make sure you don’t forget about them? Some incidents might actually be low urgency and you would use the valuable time of your engineers in tasks that might not be as important.
Hope this helps.
Just one question , why would want to increase the urgency of all incidents to high in the first place? To make sure you don’t forget about them? Some incidents might actually be low urgency and you would use the valuable time of your engineers in tasks that might not be as important.
Simply because some alert based monitoring can wait to be resolved during business hours and we don’t want to look at the PagerDuty dashboard every day (ideally, never if it was realistic).
Given most set their Low Urgency settings to email or something trivially unimportant, that leaves us with escalating to High during support hours OR now changing our Low Urgency to similar as High Urgency which defeats the point of it. It’s valuable to be able to do this.
Hi @maikel penz!
Just adding my 2 cents to what @xenda amici already replied. When you enable ‘Dynamic Notifications based on alert severity’ the incident urgency is decided based on the mapping below.
If you have high urgency incidents then you can not increase its urgency has its already high. But I see your point and we will reach out to the product team and share your feedback.
To overcome this limitation you can use our REST APIs and create a recurrent task that runs when the working hours shift start and checks for unacknowledged incidents with low urgency and increases their urgency to high.
Just one question, why would want to increase the urgency of all incidents to high in the first place? To make sure you don’t forget about them? Some incidents might actually be low urgency and you would use the valuable time of your engineers in tasks that might not be as important.
Hope this helps.
This is now over a year old. Is there any update on this feature? Any roadmap? Will this be implemented?
Also the “one question” seems weird. You have already the feature if you do statically set the low-urgency notification outside support hours and then you can escalate. The only difference with dynamic ones is, that you do not want this for _all_ your incidents, just specific ones. So questioning now why this is needed raises the question, why did PagerDuty implemented it in the other case? The same reasons why we would want this applies to both type of settings.
And asking why we would want to raise the urgency as “some incidents might actually be low urgency”.. but then as we set the “high urgency within support hours” as well, these “low urgent incidents” would only be “low” outside of support hours but if they get triggered within the support hours they would also be high urgent.. so your question still doesn’t make sense to me. Maybe you can ellaborate more on “why” you think that this feature request seems off to you.
Now I might need to use an external API/service call to “fix” this situation or use multiple services which renders the “Event Orchestration Rules” kind of useles for us, as now we do not get notified properly during the support hours for old things.
To summarize what others are saying:
Desired Behavior
