Homeβ€Ί General Discussion

Tracking downtime for a Priority Incident

Germaine_OvermanGermaine_Overman Customer IT Monkey ✭

I need to be able to identify & track service unavailability caused by a priority incident outage.

CRs have a field related to "is downtime" where you can identify when the service is unavailabe.

Is anyone tracking this as part of the closure of a priority incident? Is this via a custom form or are you doing something entirely different?

Thanks for any ideas.

Best Answers

  • Adam_DzyackyAdam_Dzyacky Product Owner Contributor Monkey ✭✭✭✭✭
    edited May 26 Answer βœ“

    There are a couple different ways you could go about this, but in short - Actual Downtime Start/End is available on Incident and Problems. All you would have to do is expose these fields with a custom Incident.js or Problem.js file such as:

    Obviously - which tab and where they are located on the form is entirely up to you. But very quick and doable is the point here.😁


    With that said, I'd be remiss if I didn't share some ideas on a potential processes you could construct around this.

    Manual -

    • This could be done with Parent/Child Incidents wherein you relate all of the employee related Incidents to a Parent and then just perform the date entry on the parent.
    • This could be done with any type of Incidents, related to a Problem wherein you define the downtime on the Problem
    • This could of course just be done on a Incident by Incident basis

    Automated -

    • This could be done with some automation via workflows and your own respective business logic such as:
      • When a P1 Incident is in a Status of Active with an Impacted Config Item set the Actual Downtime Start Date. When it is Resolved, set the Actual Downtime End Date.
      • When a P1 Incident is in a Status of Active with an Impacted Config Item increase the Actual Cost by $x every hour. You could take this even further if the Impacted CI was a Business Service since it has its own values such as priority, classification, and status.
  • Adam_DzyackyAdam_Dzyacky Product Owner Contributor Monkey ✭✭✭✭✭
    edited May 26 Answer βœ“

    I know my boss was wondering if he could use the Is Downtime Flag but I think that one is jsut available for CRs.

    It isn't 😁


  • Adam_DzyackyAdam_Dzyacky Product Owner Contributor Monkey ✭✭✭✭✭
    edited May 26 Answer βœ“

    Here's some quick PowerShell you can use to see properties for the Incident class (or others). Just make sure you have v1 of SMLets.

    Get-SCSMClass -name "System.WorkItem.Incident$" | Get-SCSMClassProperty -Recursive | sort name
    


Answers

  • Adam_DzyackyAdam_Dzyacky Product Owner Contributor Monkey ✭✭✭✭✭
    edited May 26 Answer βœ“

    There are a couple different ways you could go about this, but in short - Actual Downtime Start/End is available on Incident and Problems. All you would have to do is expose these fields with a custom Incident.js or Problem.js file such as:

    Obviously - which tab and where they are located on the form is entirely up to you. But very quick and doable is the point here.😁


    With that said, I'd be remiss if I didn't share some ideas on a potential processes you could construct around this.

    Manual -

    • This could be done with Parent/Child Incidents wherein you relate all of the employee related Incidents to a Parent and then just perform the date entry on the parent.
    • This could be done with any type of Incidents, related to a Problem wherein you define the downtime on the Problem
    • This could of course just be done on a Incident by Incident basis

    Automated -

    • This could be done with some automation via workflows and your own respective business logic such as:
      • When a P1 Incident is in a Status of Active with an Impacted Config Item set the Actual Downtime Start Date. When it is Resolved, set the Actual Downtime End Date.
      • When a P1 Incident is in a Status of Active with an Impacted Config Item increase the Actual Cost by $x every hour. You could take this even further if the Impacted CI was a Business Service since it has its own values such as priority, classification, and status.
  • Germaine_OvermanGermaine_Overman Customer IT Monkey ✭

    Adam-

    First, thanks for the information.

    Part 2, when it comes time for reporting we would query for a Priority 1 or 2 case and then pull the 2 fields and calculate the down time.

    I know my boss was wondering if he could use the Is Downtime Flag but I think that one is jsut available for CRs.

    Germaine

  • Adam_DzyackyAdam_Dzyacky Product Owner Contributor Monkey ✭✭✭✭✭
    edited May 26 Answer βœ“

    I know my boss was wondering if he could use the Is Downtime Flag but I think that one is jsut available for CRs.

    It isn't 😁


  • Adam_DzyackyAdam_Dzyacky Product Owner Contributor Monkey ✭✭✭✭✭
    edited May 26 Answer βœ“

    Here's some quick PowerShell you can use to see properties for the Incident class (or others). Just make sure you have v1 of SMLets.

    Get-SCSMClass -name "System.WorkItem.Incident$" | Get-SCSMClassProperty -Recursive | sort name
    


  • Germaine_OvermanGermaine_Overman Customer IT Monkey ✭

    Thanks, definitely gets me where I need to be.

Sign In or Register to comment.