Violation of SLA

Violation of SLA metric is the expiry of the time limit defined in the metric. Once violated, the metric is permanently visible in the history of metrics covering the given ticket (even if the ticket no longer fulfills its conditions).

A metric can be violated only once. If a violated metric ceases to cover a ticket (and was stopped due to this), and then starts to cover the ticket once again, the metric is treated as if it had been running without interruption from the very beginning.

Metric running time and the duration of ticket covered by the metric are measured and processed separately by the system.

Example:

A ticket has a “critical” priority and is covered by metric: “critical priority tickets shall be solved in 4 hours”.

The ticket is in “open” status all the time.

After 4 hours, the metric is exceeded.

After 5 hours, the ticket ceases to be of “critical” priority. The metric stops running, but it will be forever visible in the ticket as exceeded by one hour.

After 6 hours, the ticket still has the same metric visible as exceeded by one hour.

After 7 hours, the ticket is once again assigned with “critical” priority. The same metric is from now on visible as active and exceeded by 3 hours.

After 8 hours, the ticket status is changed to “closed”. The metric is irrevocably stopped with a state of exceeded by 4 hours.

When SLA metric violation occurs, a notification is generated (in the interface and as an e-mail message) to the person currently assigned to the ticket and to the e-mail address defined in the metric (if any).

For the purposes of ticket visualization in the ticket list, a dynamically generated “SLA violation date” column is defined. The column shows the earliest SLA violation date (also including overdue items) of all metrics active in relation to the ticket. If no metric is currently active, the column holds no value. If SLA time limit has expired, the value in the column is highlighted in orange.

If the ticket starts to be covered by a new SLA metric for which the time limit has already expired, the system also distributes notification about such a fact. However, each ticket cannot generate more than one time limit expiry notification for each SLA metric.

Example:

Ticket “X” is covered by metric “A”.

Metric “A” is violated.

Notification about the violation of metric “A” in ticket “X” is distributed.

Ticket “X” properties are edited in such a manner so that it is no longer covered by metric “A”.

The ticket properties are re-edited in such a manner that it is once again covered by (already overdue) metric “A”.

Repeated notification is not sent, as one notification about metric “A” in relation to ticket “X” has already been generated.