Is it possible to get SLA reporting for existing issues

Jon Arlov
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
November 18, 2013

I tried creating a service desk for our existing project that we are using for support. I hoped that once the SLA calculation was done I would be able to see reports for issues we had solved in the past based on our current SLA goals. However it appears all our old issues are marked as breeching SLA and they are all grouped on the day I installed Jira Service Desk rather than the day they were actually reported.

I guess I have two questions:

1. What is going wrong that causes all our past issues to be marked as breeching the SLA?

2. Why are all our old issues not shown with the date they were created in the reports?

3 answers

1 accepted

3 votes
Answer accepted
shihab
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
November 20, 2013

Hey Jon,

I would expect for all the issues I had before installing Service Desk to not be evaluated and therefore neither breached nor succeeded

When you enable Service Desk for a project, it creates some SLA rules out of the box to help get you started. This could be why your existing issues may have appeared as breaching SLA. If you want to define SLAs from scratch, the best way would be to delete those SLA metrics.

Whenever you update SLA metrics, be sure to click the "update" link next to the red "SLA Modified" text - this reindexes all of your existing issues so that reports reflect your new/updated SLA definitoins.

I think I may have messed up the Time to resolution SLA

In your "Time to resolution SLA" you have defined a metric (think of it like a stop watch) that:

  • Starts counting time whenever an issue is commented on (either by the reporter or by someone else for the reporter)
  • Stops counting time whenever the issue is resolved

This means that if an issue is resolved, but then after the issue gets resolved someone posts a comment on that issue, a new SLA cycle will be created - this SLA cycle will stop counting time when the issue enters the resolved state again. If your workflow doesn't allow issues to enter the resolved state again, the SLA timer will always count time and will eventually breach whatever SLA goal you have set. (For more information on SLA cycles, check out our SLA docs or for a broader overview of SLAs check out this talk around the 16 minute mark)

For time to resolution, what you probably want is to start counting time when the issue is created - so your start trigger should be "issue created".

Cheers,

-Shihab

0 votes
Intel CHD Jira Admin
Contributor
April 7, 2014

I think you might be hitting a bug, which prevents SLAs being applied to to closed issues. See https://jira.atlassian.com/browse/JSD-358.

-David

0 votes
shihab
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
November 19, 2013

Hey Jon,

I hoped that once the SLA calculation was done I would be able to see reports for issues we had solved in the past based on our current SLA goals.

There are two places where SLA calculation is evaluated in JIRA Service Desk:

  1. The time elapsed between SLA events (eg. time between "issue created" and "resolution set")
  2. Whether a particular issue passed or breached an SLA

When you create or update an SLA:

  1. JIRA Service Desk re-evaluates the time elapsed between SLA events for every issue in the project. Any reports you have that report on elapsed time will immediately reflect the new configuration so that you can gain insights from historical data.
  2. JIRA Service Desk only re-evaluates whether a particular issue passed or breached an SLA for new issues created after the SLA configuration change or for existing open issues. This means that if you change your SLA definition, issues in the past that passed/breached SLA (ie. where an SLA timer stop event has occured) will not get updated. This is intentional behaviour and it allows you to change SLA rules without affecting reports on SLA breaches / successes in the past.

To address your questions:

What is going wrong that causes all our past issues to be marked as breeching the SLA?

What is your current SLA configuration? Can you paste a screenshot?

This is likely to occur if you have an SLA definition where the SLA timer start event has fired, but the SLA timer stop event has not yet fired. So all issues in the past would still be counting time against the SLA.

Why are all our old issues not shown with the date they were created in the reports?

SLA reports on breach/success will report the breach/success on the date the SLA timer stop event was triggered, not when the issue was created. Issues that are ongoing in their SLA (timer has started but not yet stopped) but have already breached the SLA goal time are reported as SLA failures for the current day.

I suspect you may have an SLA definition where most of your old issues have started counting time, but a stop event has yet to be recorded.

Cheers,

-Shihab

Jon Arlov
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
November 19, 2013

Hi Shihab,

Thanks for writing such a detailed answer. You say "JIRA Service Desk only re-evaluates whether a particular issue passed or breached an SLA for new issues created after the SLA configuration change". If that is the case I would expect for all the issues I had before installing Service Desk to not be evaluated and therefore neither breached nor succeeded, but in the report they all show up as breached.

I'm attaching some screenshots of my configuration. If it is relevant I will also note that I installed Service Desk 1.0 when it came out, then disabled it until 1.1 because of the missing work day calendar.

I think I may have messed up the Time to resolution SLA, but the Time to first response is pretty standard, except I switched to a 9-17 monday to friday calendar.

Suggest an answer

Log in or Sign up to answer
TAGS
AUG Leaders

Atlassian Community Events