Downgrading Incidents - Multiple impacts

General discussion on all aspects of the IT Infrastructure Library (ITIL)
Post Reply
Posts: 1
Joined: Wed Feb 10, 2021 6:36 am

Wed Feb 10, 2021 6:50 am

Hi, bit of a head scratcher here... Really hoping someone can guide me.

Say a P1 is raised for a site with both of the 2 available circuits being down, what is the best approach for incident management once service is restored on one circuit but the 2nd circuit is still impacted?

The service is restored however the 2nd link is still unavailable. The P1 impact is no longer there so can be resolved however there is still an impact. This ticket could be open for a while whilst the 2nd link is fixed however the service is operational albeit with reduced redundancy.

Should the incident be downgraded to a P2 for the remaining impact? (this has an effect on reporting and SLAs), should a child incident be opened?

Not sure how to manage this, any help greatly appreciated.


User avatar
Corde Wagner
Senior Itiler
Senior Itiler
Posts: 53
Joined: Fri Nov 10, 2006 7:00 pm
Location: El Dorado Hills, California

Mon Feb 15, 2021 4:20 pm

Great question. It’s my opinion that this was one incident and by it being a “P1” it was a major incident. If you lower the priority of the incident ticket to a “p2”, then unless you have configured your tool to capture how it was handled (it was a P1) and what it was reduced to for other purposes (P2, etc.), then you are best off leaving the priority at P1 for tracking and historical purposes. I recommend not down grading the priority.

With regard to the service being restored (people can work), I would consider then incident is “over”, and you would record the time the service was “restored”; but the ticket remains open (not resolved) until the entire service is fully “recovered”. I’ve worked in organizations where we configured the ticketing system to allow us to capture both date/times (restored and resolved) and we used both metrics to tell the story of how long it took to “restore” and how long it took to “resolve”. The resolved could not be recorded until the service was fully “recovered” (which could be a third metric you track).

As you indicated in your question, leaving ticket open until the service is recovered and the incident “resolved” doesn’t look good, but by leaving it open and tracked by incident or problem management teams keeps the pressure on to actually get the service fully recovered and (the ticket) resolves. This would apply to a failed database that has been restored, but not fully recovered. Same with hardware that had failed, and customers impacted, the service restored by failing over but the service has not been recovered to “normal” until the system is switched back to primary occurs, etc.

I hope this helps.
Corde Wagner
ITIL 4 Managing Professional - ITIL v3 Expert - v2 Red Badge - VeriSM-Plus - Certified Agile Service Manager
Post Reply