I’m trying to better understand how SLA behavior is intended to work in Zammad, and whether there is a recommended way to handle this specific scenario.
Here’s the situation:
We have an SLA configured (for example, a 5-minute solution time). When a ticket is created, the SLA starts counting as expected. If the ticket is not resolved within that time, it correctly becomes overdue (shown in red), indicating an SLA breach.
However, when the ticket is eventually resolved and moved to a closed state, the SLA indicator no longer shows the violation — it appears as “normal” (green or neutral), as if the SLA had not been breached.
From an operational and reporting perspective, this is confusing. What we would expect is:
Once the SLA is breached, this status should be preserved
Even after the ticket is closed, it should still indicate that it was resolved خارج the SLA
Ideally, we would also like to see how much time the SLA was exceeded
So the main questions are:
Is this behavior expected by design (i.e., SLA is only evaluated in real time and not stored as a final result)?
Is there any native way in Zammad to persist the SLA breach status after the ticket is closed?
If not, what is the recommended approach to track SLA violations in a persistent way? (e.g., triggers, custom fields, reporting, etc.)
I’ve noticed that SLA conditions depend on ticket attributes (like state or category), and that changing these can remove/reapply the SLA. So I’m also wondering if this contributes to the behavior.
Any guidance or best practices would be greatly appreciated.
The SLA breach is evident in the reporting data. However, it might not work if you have a status condition in the SLA definition. This is something you don’t want most of the time, as states have an inherent setting if they ignore SLAs.
The *_diff_in_min are negative, if a ticket has breached it’s SLA.
Hi, thank you for the clarification and the detailed explanation.
Just to confirm my understanding: there is currently no native way in Zammad to visually display, within the ticket itself, that an SLA was breached after the ticket has been closed — for example, showing how much time it exceeded the SLA.
So in other words, even if the ticket was resolved outside the SLA, once it is closed, this information is no longer visible in the ticket view and is only available through reporting data.
This is more or less correct. There are some hacky ways to make them visible in the UI. In the end the data is present in ticket attributes. Which means, they are available as placeholder variables. And you can make adjustments to them in the rails console.
You can e.g. use triggers to write #{ticket.close_diff_in_min} into an article or copy it to a ticket attribute, you have more control over.
Can you explain in detail why you need access to that other than in reporting?
Hi, thank you all for the detailed explanations and guidance.
Based on your suggestions, I was able to implement a solution using triggers. I created a trigger that writes the value of #{ticket.close_diff_in_min} into an internal note when the ticket is closed, which now allows us to clearly see within the ticket how much the SLA was exceeded.
This approach solved our main issue of having a visible record of SLA breaches directly in the ticket, without relying only on reporting.
Thanks again for all the tips and direction — it really helped a lot!