Review and resolve incidents
Triage evidence-backed problems, inspect investigations, and move verified work toward resolution.
Incidents bring together a production problem, the evidence behind it, investigation history, and the work needed to resolve it. Use them when a finding deserves an owner and a follow-up, not for every unusual trace or detection match.
Start from the right board view
The Incidents board has three views:
| View | Use it for |
|---|---|
| Attention | Incidents that need a decision or action from the team |
| Watching | Incidents retained for monitoring rather than immediate attention |
| All | The complete incident set across attention states |
Attention is the default view. Narrow by time, priority, workflow, or other available filters when the board is large. A bounded time range is a lens over the incident set, not a change to the incident itself.
On a new project, the board can be empty while Neatlogs waits for enough telemetry to identify a supported problem. The empty state may also explain plan availability or point you back to setup. Confirm that traces are arriving before treating an empty board as proof that production is healthy.
Read an incident from evidence outward
Open an incident and move through its four detail tabs:
Overview
Read the problem statement, impact, status, priority, and current recommendation. Treat generated summaries as navigation: follow material claims to the underlying evidence before acting on them.
Evidence
Inspect the traces, detection matches, conversations, alerts, or other signals that support the incident. Check both the cited examples and the coverage notes. Missing or unavailable content should reduce confidence rather than silently count as confirmation.
Investigations
Review the latest investigation and any earlier runs. A run can be queued, running, completed, or failed. Starting another investigation does not erase a previous completed report, so compare versions when new evidence changes the conclusion.
Activity
Use the activity history to reconstruct investigations, report changes, comments, status updates, and external handoffs. Follow the recorded links to inspect the evidence or destination.
Choose the next action
The available controls depend on the incident state, project configuration, and your permissions.
| Action | What it does |
|---|---|
| Copy context | Copies a compact evidence-backed handoff for another tool or teammate |
| Investigate further | Starts or continues analysis when the current cause is incomplete |
| Give feedback | Opens the report in AI Search so you can challenge a claim, rewrite the report, or rerun the investigation |
| Fix in | Opens the selected coding agent with the implementation context when the recommendation is ready |
| Push to | Creates a ticket in Linear or Jira using your connected account |
Check the required integration, destination, and permissions before sending. Copying context is useful when no direct destination is configured, but keep the incident link with the handoff so later readers can inspect the source evidence.
Follow monitoring created by an investigation
An investigation can propose or create detections that watch for the same behavior in future traces. The incident's monitoring section shows those detections and their current status.
Before relying on one:
- open the detection and confirm its scope;
- review representative matches and non-matches;
- check whether it is active;
- define the traffic or time window required to verify recovery.
The presence of a detection does not prove the incident is resolved. Resolution needs post-change evidence showing that the original behavior stopped or returned to an accepted baseline without introducing another regression.
Keep incident and external issue roles clear
The Neatlogs incident is the evidence and investigation record. A Linear or Jira ticket is the implementation and coordination record. Link them instead of copying an uncited summary and letting the two histories drift apart.
Frequently asked questions
Does every detection match become an incident?
No. A match says that a rule fired. An incident says the team or automated incident workflow found a problem worth tracking.
Why did an incident appear automatically?
Eligible projects can be enrolled in automatic incident monitoring once enough finalized traces have arrived. Enrollment and evidence preparation run in the background; the setup state can still be collecting or enrolling before incidents appear. Neatlogs evaluates supported production evidence and surfaces a candidate when it has enough signal. Review the cited evidence before accepting its conclusion.
Why can I not see an external handoff action?
Check the project integration, repository or workspace destination, and your permissions. A personal conversational tool connection is not necessarily the same connection used for incident dispatch.
When should I resolve an incident?
Resolve it after the change is deployed and the agreed verification window supports the outcome. If evidence is still accumulating, keep it open and record the verification window in a comment.