Skip to main content
When a new incident closes and sureops detects that it matches an earlier problem, how it’s linked depends on that problem’s current status. If the match is an open problem, the incident is linked directly to it — no new problem record is created. If the match is a resolved problem, sureops never re-opens or edits it — instead it creates a new problem row, linked back to the original, so the recurrence is visible without disturbing the resolved history. Over time this builds a chain: a durable record of every time the same underlying issue has surfaced, with dates, durations, and resolution context preserved for each occurrence.

​
Why this matters

Without recurrence tracking, each incident that stems from the same root cause is resolved in isolation. Teams fix the symptom, close the ticket, and rediscover the same problem weeks later. Recurrence chains make the pattern visible:
  • How many times has this service failed in the last 90 days?
  • Is the fix applied in an earlier occurrence actually holding?
  • Are recurrences accelerating (shorter gaps) or stabilizing (longer gaps)?
When an incident closes, sureops first checks for an existing open problem with a matching signature; only if none is found does it fall back to a similarity search against resolved problems:
1

Open-problem dedup check

sureops checks whether an open (not yet resolved) problem already covers the same signature. If one is found, the incident is linked directly to that existing problem — no new problem record is created, and the open problem itself isn’t touched. This is the common case when the same live issue triggers a second incident before anyone’s finished fixing it.
2

Candidate retrieval

If no open problem matches, sureops embeds the closed incident’s problem signature — title, severity, affected services, root-cause category, error patterns, and description — and retrieves the most similar prior resolved problems by vector similarity.
3

LLM verdict

An LLM reviews the candidates and decides whether this is a recurrence of one of them or a genuinely new problem, along with a confidence score. Surface-level overlap (same service, similar title) alone isn’t enough — the root cause has to plausibly match.
4

New problem, linked to the chain

Since the only candidates at this stage are resolved problems, sureops never re-opens or mutates them — a new problem record is created and, when confidence is high enough, linked back to the resolved one, extending the chain. When confidence is too low, the new problem is still created, just without that link — it stands alone until a future recurrence connects it.
5

Notification

You get an in-app notification when a recurrence is detected — this is on by default, and in-app is currently the only delivery channel available for this event (Slack and email can’t be turned on for it). Separately, if the linked incident still has an active war-room channel and your org has notifications enabled, sureops also posts a note into that existing channel — it doesn’t send a Slack DM or open a new channel just for the recurrence. The incident timeline links to the problem; the problem detail page links back to the incident.
Problem auto-creation itself is policy-gated — whether an incident produces a problem record at all depends on its severity and closure reason, not every closed incident.
The candidate-retrieval step (matching against resolved problems) relies on an OpenAI-compatible embeddings API key being configured. If you’re self-hosting and haven’t set one up, this step silently does nothing — no error is surfaced, incidents just won’t be linked to a resolved problem’s chain. The open-problem dedup check doesn’t depend on this key.

​
Viewing a recurrence chain

Open any problem record’s detail page. If it’s part of a chain with more than one occurrence, you’ll see a Recurrence Chain card with a badge showing how many occurrences are in the chain so far — a problem with a single recurrence shows “2× so far”, since the badge counts chain depth, not the number of times it’s recurred. The card is hidden entirely for first-occurrence problems — there’s no chain story to tell yet. The card includes a View full recurrence chain link that opens a timeline of every occurrence, oldest first. Each entry shows:
  • Index in the chain, a problem identifier (this may show as an internal ID rather than a human-friendly ticket number), status badge, and severity badge
  • Title
  • Created and resolved timestamps
  • Affected services
  • RCA summary
  • A link to the Fix PR, if one exists
  • A pointer back to the problem it followed (“follows <id>”)
Between entries, the gap since the previous occurrence is shown as plain text — for example, “3 days after the previous one” — rather than as a table column.

​
Problem status and recurrences

Each individual problem record has one of these statuses: Within a recurrence chain, each occurrence is also shown with a derived chain status that’s more useful for spotting patterns at a glance:
Recurrence hotspots are tracked per service, not per problem. The Recurrence Hotspots widget on the Command Center flags any service with 2 or more problems in the trailing 30-day window, regardless of whether those problems are formally chained together, and shows the top 3 affected services. This is a strong signal of an unresolved or recurring root cause worth deeper investigation.

​
Frequently asked questions

Can a single problem appear in multiple recurrence chains? No. Each problem links to at most one prior problem via its recurrence pointer, so it belongs to exactly one chain. Does a recurrence change the earlier problem’s AI analysis? No — an existing problem’s own AI analysis is never rewritten by a later recurrence. What happens next depends on whether that problem is still open or already resolved: if it’s open, the new incident is simply linked to it directly, with no separate problem record involved. If it’s resolved, sureops creates a new problem record with its own fresh RCA, generated from the new incident’s data — the original, resolved problem’s analysis and resolution history stay exactly as they were. What if no matching problem exists? A new, unlinked problem record is created — the start of what may become its own chain if the same issue recurs later.
  • Tracker sync — push problem records to your issue tracker
  • Incident channels — how sureops posts recurrence notes into an incident’s existing Slack war room