Incident Detection
Group a wave of similar tickets into one incident, automatically.
What it does. During an outage the same problem arrives as many separate tickets. This agent notices they are the same problem, promotes one of the existing tickets to be the incident, and links the others to it. It never creates a new issue — the incident is always one of the tickets your customers already raised.
When it runs. Twice over: immediately when a ticket is created, and again on a recurring scan whose interval you choose. The scan catches a wave that builds slowly, which the per-ticket check would miss.
Project settings → AI Triage → Incident DetectionIllustration
AI Triage
StatisticsDispatcher AgentSmart EscalationIncident Detection
Enable Incident Detection
Detect clusters of similar tickets and promote one of them to a major incident.
▾ General SettingsCollapse
Scan Interval
Every hour
How often to scan for trending issues.
Time Window (minutes)
90
Look back this many minutes when scanning for similar issues.
Cluster Threshold
10
Minimum number of similar issues to trigger incident creation.
Link Type (required)
relates to
Jira link type used to link related issues to the incident.
Which issue types are incidents (required)
Incident
Choose at least one issue type, or the detector cannot tell which tickets are incidents.
Custom AI Instructions
Additional instructions for issue clustering...
Optional instructions appended to the clustering prompt.
The settings that decide whether this is useful or noisy
| Setting | What it means | How to choose |
|---|---|---|
| Scan Interval | How often the recurring scan runs. A dropdown: Every hour, 2, 4, 6, 12 or 24 hours. One hour is the floor and the shipped default. | Every hour for most desks. This is the slow half of the feature — a sharp outage is caught by the per-ticket check within seconds of the tickets arriving, so a longer interval costs you less than it looks like it does. |
| Time Window (minutes) | How far back a scan looks for similar tickets. Ships as 90. | Match how fast your customers actually report things. A shorter window catches sharp spikes; a longer one catches a slow degradation. |
| Cluster Threshold | How many similar tickets are needed before an incident is created. Ships as 10. | Look at your last real outage: how many tickets arrived inside your time window? Set it just under that number. |
| Link Type | The Jira link type used to attach tickets to the incident. Required. It starts unset, showing “-- Select link type --”, and the screen will not let you save an enabled agent without it. | relates to, unless your team already uses something else. |
| Which issue types are incidents | Required. Which issue types the agent may promote to be the incident. It is a separate question from the filter below, and the screen says so: without it the detector cannot tell which tickets are incidents. | Your desk's Incident type, if it has one. Otherwise the type your team actually treats as an outage record. |
| Custom AI Instructions | Extra rules for grouping. | Say what to group on and what never to group. For example: “group by affected service, not by wording” and “never cluster password resets”. |
- Service Desks — which desks are monitored.
- Issue Types (optional filter) — which tickets are analysed. Leave it empty to analyse everything.
- Only process tickets matching this JQL — the same filter the other two agents have. A ticket that does not match is never looked at.
What happens when a cluster is found
- 1The agent works out the common topic across the tickets and picks one of them as the principal.
- 2It promotes the clearest ticket in the cluster: it sets Jira Service Management's Major incident field on that ticket. If your site has no such field, it falls back to adding a
major-incidentlabel, so the promotion is still visible and still queryable. - 3It links the rest of the cluster to that ticket, using the link type you chose.
- 4Each ticket's AI Triage panel shows which incident it belongs to, and whether it was matched immediately or by a scheduled scan.
Start high, then lower it
Set the threshold higher than you think you need. An agent that creates one incident during a genuine outage is valuable. One that creates incidents for every pair of vaguely related tickets gets ignored within a week, and then it is worthless even when it is right.