Incidents Inbox
Alerts, uptime outages, security detections and manually created incidents share one list and one API. You see what needs attention in one place, whoever or whatever raised it.
Overview
Open Incidents in the sidebar. The list shows status, severity, title, source, project, assignee, age and the time of the last event. It defaults to incidents that are Open or Acknowledged and can be filtered by source, severity, assignee (Me, Unassigned, Anyone) and project. You can acknowledge, resolve or assign several incidents at once, and the list updates live.
An incident page shows one merged timeline of events, comments and status history, with actions in the header and a panel specific to the source.
Sources
| Source | API value | Created when |
|---|---|---|
| Alert | alert | An alert rule starts firing. While it keeps firing, new triggers update the same incident. |
| Monitor | monitor | An uptime monitor reaches its failure threshold and is reported down. |
| Security | sigma | Detections are grouped into a security incident, with MITRE tags, IP reputation and geo data. |
| Manual | manual | A member creates one, for example through POST /api/v1/siem/incidents. |
An alert incident takes its severity from the levels the rule watches: critical
gives critical, error gives high, warn gives medium, anything else
low. An incident's severity can escalate while it is active but never drops on its own.
There is at most one active (open or acknowledged) incident per alert rule or monitor. A
resolved incident is never reopened by the source: the next failure opens a new one.
No extra notification
Alert and monitor incidents do not send an additional "incident created" notification. The alert or monitor notification already went out, and it links to the incident. Security incidents keep their own notifications.
Statuses
| Shown as | API value | Meaning |
|---|---|---|
| Open | open | New and not yet picked up. |
| Acknowledged | investigating | Someone is on it. LogTide records who acknowledged it and when. |
| Resolved | resolved | Fixed, or recovered on its own. LogTide records who resolved it and when, or that it recovered automatically. |
| False positive | false_positive | Security incidents only. Setting it on any other source is rejected with HTTP 409. |
The stored status values did not change; the interface labels investigating as
Acknowledged. Setting an incident back to Open clears its resolution.
Working an Incident
- Acknowledge - tells the team you are looking at it. An already acknowledged incident is left unchanged.
- Assign - to any member of the organization, or to nobody. Assigning to someone outside the organization is rejected.
- Resolve - closes the incident. You can add a comment first; comments appear in the timeline.
- Mark false positive - security incidents only. From a security incident you can also add a detection rule exception based on the logs that matched.
- Publish to status page - on a monitor incident, creates a pre-filled status update for your public page.
Bulk actions work on up to 100 incidents per request. Incidents the action does not apply to (for example acknowledging a resolved incident) are skipped and reported in the response; the rest are updated.
Auto-Resolve
Alert incidents
Resolved automatically when the rule returns to OK. Also resolved when you disable or delete a rule that is firing, so no incident is left open for a rule that no longer runs.
Monitor incidents
Resolved on recovery when the monitor's Resolve the incident automatically on recovery option is on (the default). With it off, the incident stays open until someone resolves it.
A snoozed alert rule does not stop its incident from resolving: snoozing silences triggers and re-notifications, never the recovery. See the alert lifecycle.
Links From Alerts and Monitors
- The notification an alert sends (email, Slack, Teams, webhook) links to
/dashboard/incidents/<id>when an incident exists.alert.triggeredandalert.resolvedwebhook payloads carryincident_id. - Uptime down and recovery notifications link to the monitor's incident in the same way, and carry
incident_id. - The incident page shows a source panel. For an alert it summarizes the rule and offers Show matched logs, which opens the Logs explorer with the rule's criteria and the trigger window. For a monitor it links to the monitor with its status and response time. Each trigger or failed check appears in the timeline.
API
The incidents API requires a signed-in user who is a member of the organization. Every call
carries organizationId. /api/v1/siem/incidents remains as an alias
of the same routes; it now returns incidents of every source, so add
source=sigma to get the previous security-only result.
| Endpoint | Purpose |
|---|---|
GET /api/v1/incidents | List. Filters: status, source, severity, projectId (several allowed), assignee (me, unassigned, anyone or a user id), ruleId, service, technique. Sort by last_event_at, created_at or severity. limit up to 100. |
GET /api/v1/incidents/:id | Detail with detections, comments, history and the alert triggers or monitor checks behind it. |
PATCH /api/v1/incidents/:id | Change status, assigneeId (null unassigns), severity, title or description. |
POST /api/v1/incidents/bulk | action is acknowledge, resolve or assign; up to 100 ids. |
GET · POST /api/v1/incidents/:id/comments | Read or add comments. |
GET /api/v1/incidents/:id/history | Status, assignment and severity changes. |
# Acknowledge an incident
curl -X PATCH http://localhost:8080/api/v1/incidents/INCIDENT_UUID \
-H "Authorization: Bearer YOUR_SESSION_TOKEN" \
-H "Content-Type: application/json" \
-d '{ "organizationId": "ORG_UUID", "status": "investigating" }'