Combining multiple incidents


(Tim Boring) #1

I have a use case where I want to combine multiple incidents into one, because it turns out they were all related to a single release being pushed to production. I want to do this because I want to include a note that identifies the release and PR that cause the incidents; I’d rather not have to add a note to every single incident.

(Alex Maier) #2

I think this may help:


  1. Use the checkboxes to select the incidents
  2. Next, select Merge Incidents.
  3. In the popup, you can choose which incident you would like all of the alerts to be grouped under. When merging, you also have the ability to update the incident summary to more accurately reflect the problem.
  4. The incident dashboard will show a single incident. When you click to open the Incident and view its details, the alerts that you merged will be listed as the incident details.

Hope this helps!

(Tim Boring) #3

Ah, that’s exactly what I was looking for. Clearly I’m just blind! Thanks! :slight_smile:

(Alex Maier) #4

No worries, glad to help!

(Arpanbhagat5) #5

Hello Alex
I was trying the same feature (of incident merging). I found the following two issues:

  • The merged incidents go to “RESOLVED” status by default.
  • I couldn’t see the list of incidents that got merged when I opened the parent incident (the incident I merged all the others into)

Can you please tell, what did I miss? Thank you :bowing_man:

(Chiedu Uraih) #6

Hello @arpanbhagat5,

You did not miss anything. That is the expected behaviour when Incidents are
merged. Those merged incidents will point to the Parent Incident.

Please see the article on Merged Incidents here for more details.
I hope this helps.


(Arpanbhagat5) #7

Yes, I figured that out later. Thank you.

On a different topic, Can we create a workflow for a ‘customized responder assignment’ for a service.
For example, ‘user-admin’ request processing use case

  • For some alert A created by an event E on service S by a user U1, we need to assign a particular user U2.
  • Think of this as U1 being a developer and U2 as a leader/admin.
  • This becomes a case of request approval than that of an event(issue) that has popped up in the service S

The obvious way would be to divide these unique events into separate services and assign the U2 person as required. But, for a team of 200 or so people, creating 200 services would be messy. So, any elegant solution to this?

Possible solution?
Under event rules, we can cherrypick alerts based on a certain criteria, so we set the user name using custom details.
But, after that we can’t assign someone for that selected alert.
I know the purpose of Event rule was to suppress the alerts and not create more actions out of it.
But, if we could, it would have solved the problem mentioned above.

Update : I delved into the developer.pagerduty (!/Incidents/post_incidents). It seems we can set assignee while creating the incident itself. Is this relevant to the use case I mentioned above?

(Chiedu Uraih) #8

Hello @arpanbhagat5,

Many thanks for your feedback!

Currently, Event Rules route Alerts to Services, in so doing Teams that monitor the Service.
However, I will be raising this as a Feature Request with Product Team to consider.


(Arpanbhagat5) #9

Thank you for taking the request into consideration.
I was trying a simple incident trigger using API v2.
I used the following request

$ curl -X POST --header ‘Content-Type: application/json’ --header ‘Accept: application/’ --header ‘Authorization: Token token=y_XXXXXXXXXXXXXXXXXXX’ -d ‘{
“incident”: {
“type”: “incident”,
“title”: “Command monitoring: Investigate cmd”,
“service”: {
“id”: “P123456”, #My test service
“type”: “service_reference”
“urgency”: “high”,
“body”: {
“type”: “incident_body”,
“details”: “Sudo command was run. You should investigate.”
“assignments”: {
“assignee”: {
“id”: “P789123”, #my user name
“type”: “user”
}’ ‘’ -v

to which, I got the following message:

{“error”:{“message”:“Access Denied”,“code”:2010}}

Can you help me how to test the API commands?
Point me to some reference (about expected error codes etc.) if the need be.

Thank you

(Chiedu Uraih) #10


The issue here is that you are using the default token on the system when you
should have generated one on your account. For more details on this please
refer to PagerDuty’s documentation
on this subject.

Can I point out that it is not advisable to place such details regarding your account in a public
like this. If you have further details regarding this, please do email


(Arpanbhagat5) #11


it is not advisable to place such details regarding your account in a public

Thank you for the caution. Will take care from the next time.

I understood the usage of token also. Thank you

Arpan Bhagat

(system) #12