What is a problem record?
A problem record is created when:- An incident recurs with the same root cause (sureops detects this automatically and creates a new problem record, linked back to the prior one — see Recurrence chains below)
- An incident is manually promoted to a problem by a team member using the Promote to problem button on the Incident Hub
- The post-closure analysis agent identifies a pattern that warrants structural follow-up
- A root cause analysis (RCA), attributed on-screen to Problem Commander
- A status: Investigating, Root Cause Identified, In progress, or Resolved
- A single linked incident — the one that triggered this problem record
- Action items — some agent-generated, some added manually by your team
- Agent-produced follow-ups where applicable, each as its own card: proposed monitors, a runbook, and a fix PR opened against the relevant service repo when GitHub is connected
Viewing the problem list
Navigate to Problems in the sidebar to see all problem records for your organization. Unlike incidents, problems are organization-scoped, not environment-scoped — switching the environment context switcher does not change the problem list. Each card in the list shows:- A stage badge reflecting where the fix currently stands (e.g. Investigating, Root Cause Identified, Remediation, Resolved)
- A category chip
- An aging badge showing how long the problem has been open
- A recurrence badge (
×N) when the same root cause has recurred more than once - The problem title
- The originating incident’s external ID
- The assigned owner (if set)
- A relative timestamp for when the problem was created
Problem detail page
The problem detail page shows the full picture for a single problem record.Root cause analysis
The RCA is a structured analysis attributed on-screen to Problem Commander. It’s organized into sections including Summary, Incident Timeline, Root Cause, Contributing Factors, Evidence, a conditional Recommended Fix, Impact, Resolution, and Lessons Learned.Linked Incident
A single Linked Incident card pointing to the one incident that triggered this problem record, with a link back to its Incident Hub. If this problem is part of a recurrence chain (more than one occurrence of the same root cause), a separate Recurrence Chain card appears alongside it with a link that opens a dedicated recurrence-chain page — a full timeline across every problem record in the chain. That card hides itself entirely for a first-occurrence problem, since there’s no chain yet to show. See Recurrence chains below.Action items
The Action Items card tracks specific follow-ups for the problem, grouped into Near-term and Long-term. Some are generated automatically by the agent; you can also add your own with the Add button in the card header. Action item status is tracked as Pending, In Progress, Done, or Blocked. Each item shows its assignee as a read-only field — there’s no UI to (re)assign one to a team member — but you can advance its status (and mark it complete) as your team works through it. Proposed monitors, a runbook, and a fix PR are not sub-types of this action-items list — each is its own separate card on the problem detail page, described below.Proposed monitors
When the agent identifies metric thresholds or alert rules that would have caught this incident automatically, they appear on a dedicated Proposed Monitors card, staged for your review before being pushed to your provider.Runbook
When the agent drafts runbook updates based on what was learned from this problem, they appear on a dedicated Runbook card, attributed on-screen to Problem Commander.Fix PR
When GitHub is connected and the agent identifies a code fix, a PR is opened in the relevant service repository. The PR link appears on the problem detail page. Whether the PR stays a draft for your review or gets auto-merged depends on your org’sgithub_auto_merge setting — that setting is silently enabled if you skip providing a GitHub username during onboarding. See Post-Closure Agents for the full behavior.
Recurrence chains
When the same root cause triggers a new incident after the original problem is closed, sureops never reopens or edits the resolved problem record. Instead it creates a brand-new problem row — with its own single linked incident and its own fresh RCA — and links it back to the prior problem, extending the chain. Each problem in the chain stays exactly as it was resolved; only the newest entry is ever written to. The chain grows over time:A resolved problem is never reopened, and never mutated, when a recurrence is detected. Instead, sureops creates a new problem record linked to the original recurrence chain. This preserves the historical RCA and action-item record for every resolution attempt separately.
Linking incidents to problems
From any Incident Hub, you can manually promote the incident to a problem using the Promote to problem button in the incident header’s action cluster — the incident doesn’t need to be closed first. The button hides itself once the incident is already linked to a problem, or for closure reasons (like superseded or no-remaining-alerts) that never established a real root cause. This is useful when you spot a pattern before automatic detection fires. If sureops has already linked an incident to a problem record, that link appears on the Incident Hub header for the incident — the Incidents list itself doesn’t show a problem-record indicator per row.Problem status lifecycle
There is no separate “Open” status — the Open filter on the problem list simply means “not yet resolved” (any of the first three statuses above), not a distinct value stored on the record.
Marking a problem resolved does not prevent a new problem from being opened if the same root cause recurs. The recurrence chain ensures historical context is never lost.