Triage
Review incidents that detectors created, inspect the session, and move each incident to Acknowledged or Resolved.
Watch the workflow: Inspect and acknowledge an authored incident · Authored dummy data
The video shows the earlier Triage navigation. Migrated workspaces use Investigations → Incident intake for this queue.
Filter the Tensile triage queue to new incidents, inspect one authored incident and acknowledge it. The missing evidence reference remains visible. These rows are manually authored fixtures, not actual detector output. Acknowledgment is a queue state, not a customer outcome or incident resolution.
Read the walkthrough transcript
- 00:00 — Filter new incidents in Tensile. These rows are authored demo fixtures.
- 00:05 — Inspect one incident. Its evidence reference was not recorded.
- 00:11 — Acknowledge the incident. This updates the queue, without proving customer success.
After your workspace migrates Triage, open Investigations → Incident intake. Before migration, use Triage. Each detector incident keeps its customer, failure type, severity and status.
An incident and an Investigation have separate lifecycles. Acknowledging, resolving or reopening an incident does not change an Investigation's state. Migrating an incident does not create a new Investigation or run a model.
Existing Triage URLs remain usable. After the migration reconciles, they redirect to intake and preserve supported filters and selections. Rollback restores earlier navigation without deleting incidents or their Investigation links.
Before you start, send events to Tensile and wait for a detector to create an incident. Raw failed events are separate. Find them in Error Captures.
Read the queue
The three cards show how many incidents are New, Acknowledged and Resolved. They cover all time for the selected customer.
The table lists the Customer, Failure, Severity, Seen, Last and Status of each incident. Severity is low, medium, high or critical. Seen is how many times the detector found the incident.
- Choose a customer in the customer list, or keep the organization-wide view.
- Set Status to All incidents, New, Acknowledged or Resolved.
- Select Load more to read the next 50 incidents.
Review one incident
- Select the failure name in a row. A details pane opens.
- Read the severity, times detected, last seen time, session and evidence reference.
- Select Inspect full session to check the recorded session before you decide what happened to the customer.
- Select Acknowledge incident for a new incident, or Resolve incident for an acknowledged one.
- Select Reopen incident to return a resolved incident to New.
After a change, a notice names the new status. Select its link to see the incident in that status.
Empty and failed states
- An empty queue does not establish healthy operation. The page shows detector coverage separately from raw failed events and preserves unavailable reads.
- When the selected status has no rows but other incidents exist, change the status filter.
- When raw failures exist, follow the Error Captures link. Its customer, date window and cutoff match the count on Triage. Detector last-run status remains unavailable.
- If a status change fails, an error appears above the table. The incident keeps its old status.
Next steps
In Incident intake, an owner or admin can explicitly link an incident to a permitted Investigation or create a new Investigation for it. The customer and workflow scope must match. Other members retain their existing incident-status permissions.
A link retains the incident's canonical identity and current status. It does not establish customer resolution or invent earlier status transitions. Opening a linked Investigation does not start a run.