HaloPSA

HaloPSA Guides

Documentation to assist with the setup and configuration of the HaloPSA platform

Guides > Service/Application Availability Management

Service/Application Availability Management

In this lesson we will cover:

- What is Service availability tracking?

- How to set up service availability tracking

- Be notified if a service is down

- Reviewing downtime 



What is Service availability tracking?

Service and application availability tracking in Halo allows you to track the amount of uptime and downtime that has occurred against your services and applications within a set period. This allows you to measure SLTs, SLOs, SLIs based on outage data from core ITSM processes. HaloPSA customers will also benefit from this functionality as being able to track the availability of a service ensures you are meeting the service level agreements you have with your customers, improving the quality of your service. Service availability tracking allows you to identify patterns and trends in service issues which can hep improve service reliability longer term. 


Data showing high uptime reliability can also be used a selling point for potential new customers!


Service availability tracking uses tickets that are linked to a service to log downtime against the service, with the duration the ticket is open for assumed to be the amount of time the linked service/application is 'down'. This functionality works in conjunction with ticket driven service status monitoring, ensure this is set up before setting up service availability tracking. See our lesson Service Status Monitoring here. 


How to set up service availability tracking

To enable this functionality head to configuration > service catalogue  the setting "Track service availability to monitor performance".

Fig 1. 'Track Service availability to monitor performance' 


When enabled you will have the option to enable availability tracking per service/application.


Service Configuration

Head to the services module and select the service you would like to enable availability tracking for. Ensure this service is marked as a monitored service and you have set up ticket driven service status monitoring. Head to the 'monitoring configuration' tab and enable the setting 'Track Service availability to monitor performance'. Once enabled the 'Service availability Tracking' section will be available. 

Fig 2. 'Track Service availability to monitor performance' against a service


Now you can configure uptime targets for this service/application. A "Target Period" can be specified as weekly, monthly, quarterly, or yearly. The "Target Uptime %" allows you set the percentage uptime target for each period for this service/application. The percentage is based on the number of downtime hours vs the working hours for the period, which are based on the "Working hours to check" field against the service. You can also specify "Days after period end to calculate period availability" to delay the calculation slightly to allow records to be amended.


Fig 3. Setting uptime targets for the service/application


Now ticket types will need to be configured to determine when they are marked as downtime. 


Ticket Configuration

There are two ways to mark a ticket as downtime. The "Is Downtime" field can be added to the field list at ticket type level, when this field is checked the ticket will log downtime against the related service. Ticket rules can be used to automatically have a ticket log downtime if the ticket meets set criteria. 


Downtime field

Head to configuration > tickets > ticket types > select the ticket type used to log incidents/update the status for the chosen service > field list, here add the field 'Is downtime'. The fields 'Start date and time' and 'Target date and time' can also be added, these fields allow you to override the duration of downtime the ticket logs. If these fields are not populated the duration of downtime will be determined using the date/time the ticket was logged and when it is closed. If these fields are present the duration of the downtime will be determines using the start/target date and time fields, allowing the duration of downtime to be set manually. 

Fig 4. Fields required to have a ticket log downtime against a service. 


The 'Related service catalogue' field will also need to be present to link this ticket/the downtime to the relevant service/application. 


A default for the 'Is downtime' field can be set under the 'defaults' tab of the ticket. 


Field visibility:

The visibility of the 'If downtime' field can be set by editing the field in the field list. It is recommended to have this field visible to agents only to avoid users logging downtime for a service incorrectly. 

Fig 5. Downtime field visibility 


Ticket Rules

Use the 'Configure Rules' button against the service to create a new ticket rule. 


Set the criteria for the rule, the example criteria shown in figure 6 will have the ticket log downtime when the ITIL ticket type is 'Problem' and the related service catalogue field is populated with one of my monitored services. 

Fig 6. Example rule criteria


Now under the 'Outcome' section of the rule set the outcome to be 'Is downtime' 'Yes'.

Fig 7. Downtime outcome


The downtime field should still be in the ticket's field list is you are using the rule to log downtime, but the field visibility can be set to hide from agents and users. This is useful when you would not like agents to be able to toggle whether a ticket will log downtime and instead only have this determined by set criteria. 


Notifications for when a service is down

Notifications can be configured to alert agents/users when a service is down. 


To set this up create a notification as usual, assigning the users/agents you would like this notification to send to. For information on creating notifications see our lesson here. 


Set the event trigger to be 'new ticket logged - All' and add criteria 'Is Downtime is equal to Yes'.

Fig 8. Trigger for downtime notification


In the figure 8 example a notification will trigger when a new ticket has been logged and the downtime field has been checked. Who the notification sends to will depend on your notification configuration. 


Reviewing Downtime

When the field is set and the primary service of the ticket is set to a service that tracks downtime, a downtime record will be created, with the start date based on the date occurred of the ticket, unless a start date is specified in the start date field. If the ticket is no longer marked as downtime, or the service changes, the downtime record will be removed.


Once the ticket is closed, the downtime will be marked as ended and a record will be created for every working day between the start and end dates of the ticket, with the end date being the date cleared of the ticket, unless a target date is specified in the target date field.


Completed downtime will be visible on a timeline in the "Downtime Timeline" against the service.

Fig 9. Downtime timeline against service


Service Availability History

The history of the service's availability and if the target uptime hours have been met can be viewed in the 'Availability history' tab of the service. 


Each day a scan will run to check if a service availability record needs to be created. If the end of the period plus the days to delay have passed, a service availability record will be created for that period. This will contain the start and end dates for the period, the total hours in the period, the total downtime hours, the percentage uptime, and whether or not the target was met.


The availability records can be viewed in the "Availability history" tab of the service.

Fig 10. Availability history tab


Note: The first availability record will not be present until the first period has passed since enabling this functionality for this service. 


If a new downtime record is added for this period after the calculation, the availability will be recalculated. Downtime records can be logged retrospectively using the 'Start date/time' and 'Target date/time' fields against the downtime ticket. 

Popular Guides