How to Calculate SLA from Actual Outage Time When JSM Access Is Delayed?

[Adrian Carty]

We utilise Jira Service Management as our primary ITSM tool. However, due to the nature of where our instance is hosted, the system cannot be accessed remotely.

This creates a challenge for accurate SLA reporting during after-hours events. In these scenarios, the on-call member may take up to 30 minutes to attend site before they are able to raise the incident record. As a result, the ticket creation timestamp does not accurately reflect the actual outage commencement time, which skews our SLA metrics.

I’ve explored using custom Date/Time fields (e.g. “Outage Start Time”) that can be manually populated when the incident is raised. However, it does not appear that SLA reporting can easily account for custom open/close timestamps in place of the system-created Created and Resolved fields.

Has anyone implemented a clean and defensible way to:

• Start SLA measurement from a manually entered Date/Time field?
• Adjust SLA reporting to reflect actual outage commencement time rather than ticket creation time?
• Or otherwise handle delayed ticket creation in restricted-access environments?

[Alina Kurinna _SaaSJet_]

Hello @Adrian Carty 

Standard JSM SLAs rely on system timestamps. They typically start counting from the Created event or status transitions defined in the SLA configuration.

If your operational reality doesn’t match your system events, you need more flexible SLA logic.

In your case, the outage may begin up to 30 minutes before the ticket is created due to restricted remote access. Unfortunately, the standard JSM SLA configuration does not allow you to backdate the SLA start time to a manually entered Date/Time field. Fields like Negotiated Date only adjust the target, not the actual SLA start timestamp.

If you are open to considering Marketplace apps, there is an approach that handles exactly this scenario. My team developed SLA Time and Report for Jira specifically for more complex and real-world SLA logic.

Our app:

• allows configuring flexible Start conditions

• supports custom Date/Time fields

• includes multi-cycle SLA logic

• supports reset rules

• calculates SLA not only from system fields, but from defined conditions

How can it be implemented in SLA Time and Report

1️⃣ Create a custom field
Outage Start Time (Date/Time)

2️⃣ Configure the SLA:

Start condition:
→ when Outage Start Time is not empty

Time calculation:
→ calculated from the value of this field

Stop condition:
→ Status = Resolved

3️⃣ Optionally:

• Add a reset condition (if incidents are reopened)

• Add escalation actions

• Use multi-calendar configuration (especially useful for after-hours and on-call scenarios)

With this setup, the SLA is calculated from the actual outage start time, not from the Created timestamp, making your reporting much more accurate and defensible for audits or stakeholder review.

On top of that, SLA Time and Report provides detailed SLA reporting and analytics that help you clearly demonstrate performance.

If you have any additional questions or would like help with the setup, you’re welcome to book a 1:1 call with our Product Manager. They can walk you through the configuration and help tailor the setup to fit your specific workflow and operational constraints.

In any case, you can start with a trial to see whether the app fully covers your requirements and aligns with your SLA reporting needs.

Regards!

[Jorge Cammarota]

Hello good morning You touched on a very sensitive point of JSM in restricted environments: the native SLA always starts from system events (Created, status transition, comment etc.), and not from an arbitrary date/time field. In Data Center this continues to be true, so the “clean and defensible” way out is to model the real SLA outside the native mechanism, using fields and automation/script.
Below I will leave a practical attempt that I have seen work well in Data Center remembering that it may work or may not work each business rule is one.
Since the SLA cannot “start” directly in a customized field, the idea is:
Register the real start of the unavailability in a Date/Time field.
Calculate the opening delay (how much time passed between this real start and the ticket creation).
Adjust the real interruption time using:
Time between Created → Resolved (or your native SLA)
opening delay.
This way, the native SLA remains intact and auditable, but you gain a corrected view for the business.
Suggested fields
Create these custom fields in the Incident project (JSM Data Center):
Início real da indisponibilidade
Type: Date Time Picker
Filled in manually by the on-call analyst when registering the incident (based on the monitoring log, call time, etc.).
Atraso de abertura (minutos)
Type: Number field
Will store the difference in minutes between the previous field and the Created.
(Optional, but very useful) Tempo de resolução real (minutos)
Type: Number field
Will store the total interruption time, already with the opening delay added.
If you prefer to use only native Automation
Depending on the version of Jira/JSM Data Center, Automation can already handle date differences.
The logic would be:
Trigger: Issue created or “Field value changed: Início real da indisponibilidade”.
Action: Edit issue → set the Atraso de abertura (minutos) field with the difference between {{issue.created}} and {{issue.Início real da indisponibilidade}}.
If your version does not support this type of calculation natively well, ScriptRunner could be an alternative anything bring if you solved it or not so that the community can help you