A breach alert cannot change the outcome, so what is it for? The case for firing exactly once, why the real deadline is the target plus the sweep interval, and who should hear about a late ticket that nobody owns.
Most tools will happily tell you an SLA has been missed. Fewer have thought about who should hear it, how often, and what the notification is actually for — and those three questions decide whether breach alerts get acted on or filtered into a folder nobody opens.
Here is the reasoning behind how Ticku handles it, and the trade-offs in each decision.
A breach alert is not a reminder
The distinction matters because it determines the design. A reminder is sent before a deadline and its job is to change the outcome. A breach notification is sent after, and the outcome is already fixed — the target was missed and no notification un-misses it.
So what is it for? Two things, both retrospective:
- Somebody now needs to decide what to do about a ticket that is late, which is a different decision from working the queue in order.
- The miss needs to be visible to somebody other than the person who missed it.
That second one is the whole reason the notification exists. A breach that is only visible in a report nobody runs is not a control.
Fire once, ever
The single most consequential choice here: a breached ticket notifies once, and never again.
The tempting alternative is to re-notify — hourly, daily, until the ticket is resolved. It feels more responsible. It is not. An alert that repeats on a ticket you already know about trains people to dismiss it, and the dismissal habit generalises to the alert that is new. Once you are reflexively clearing SLA notifications without reading them, the channel is dead, and it is dead for the genuinely urgent one too.
So each ticket carries a flag saying it has already announced its breach, and the check skips it forever after. The escalation path for a ticket that stays late is escalation — a deliberate act by a person — not a louder version of the same alert.
The cost of this choice is real and worth stating: if the one notification is missed, nothing repeats it. That is the trade. It is made deliberately, because a channel people still read is worth more than a channel that repeats.
Your real deadline is the target plus fifteen minutes
Targets in Ticku come from the priority, and they are the same for every Support project:
| Priority | Target |
|---|---|
| Critical | 4 hours |
| High | 8 hours |
| Medium | 24 hours |
| Low | 72 hours |
But the check that finds breaches is a scheduled sweep, not a timer per ticket. It runs every fifteen minutes.
Which means the honest statement of behaviour is: a Critical ticket breaching at four hours notifies somewhere between four hours and four hours fifteen. Not "instantly at four hours".
That is a defensible interval — fifteen minutes of imprecision on a four-hour target is under 7%, and on a 72-hour target it is noise. It matters that it is stated, though. A vendor implying per-second breach precision is either running a timer per open ticket, which does not scale, or rounding the truth.
A per-ticket scheduled job would give you exactness and buy a scheduling entry for every open ticket in the system, each of which has to be cancelled or rescheduled whenever a due date or status changes. A sweep costs one query every fifteen minutes and cannot drift out of sync with the data, because it is the data. For a deadline measured in hours, the sweep is the right shape.
Who hears about it
Assignees. And if the ticket has no assignee, the person who created it.
That fallback is the part that took thought. An unassigned ticket is exactly the one most likely to breach — nobody owns it, so nobody is watching it — and a notification model that only tells assignees would say nothing at all about the tickets most likely to go wrong. Falling back to the creator guarantees a breach always reaches at least one human.
Two further constraints:
- Resolved tickets are excluded. A ticket already fixed or closed is not breaching; it is finished. Only work still genuinely open is checked.
- SLA applies to Support projects only. Consulting, Dev and Epic projects have priorities but no target, because a consulting engagement's deadlines come from a statement of work, not from a priority field. Inventing an SLA for them would produce alerts nobody agreed to.
Failed notifications retry; delivered ones do not
A small detail with outsized consequences. The breach flag is written only for the tickets whose notification actually dispatched. If dispatch fails for a ticket, that ticket stays unflagged and is picked up on the next sweep fifteen minutes later.
Without that, a transient failure during the sweep would mark the ticket as announced and swallow the alert permanently — the "fire once" rule turning into "fire zero times" because of one bad minute. Marking on success rather than on attempt is what makes "once" mean "at least once".
Escalation is the other half, and it is off by default
Breach notification tells you a target was missed. Escalation changes who owns the problem, and in Ticku it is deliberately a separate mechanism.
Escalation can be automatic after a configurable number of days — three by default, adjustable from one to ninety — but the whole feature ships switched off. That is intentional. Auto-escalation on a queue that has not yet been tuned produces a flood on day one, and the first thing anybody does with a flood is turn the feature off and never revisit it. Off by default means the team turns it on when they have a reason to.
Manual escalation is also permission-gated: by default only the lead-tier role of each project type can escalate, and every escalation carries a reason. That reason field is doing real work — an escalation record that says only that something was escalated tells a future reader nothing, and the "why" is the part that is impossible to reconstruct three weeks later.
The short version
If you are evaluating any tool's SLA handling, four questions:
- How often does it check? Your real deadline is the target plus that interval.
- Does it re-notify? If yes, ask how they stop people tuning it out.
- Who gets told when a ticket has no assignee? If the answer is nobody, the tickets most likely to breach are the ones nobody hears about.
- What happens if the notification fails to send? If the ticket is marked as notified regardless, "once" can mean "never".