Incidents

Incidents surface when something goes wrong — a blocked action, a failed execution, an anomalous pattern, or an explicit escalation. They are your starting point for investigation and response.

What Creates an Incident

Incidents are created automatically or manually in several situations:

• Blocked actions — when a policy blocks an action, an incident is created to ensure visibility
• Failed executions — when a connector fails to execute an approved action
• Rejected approvals — when an approver rejects an action, an incident records the decision
• Agent errors — when a run ends with an error status
• Manual escalation — operators can create incidents manually for anything that warrants investigation

Incident Severity

Each incident has a severity level:

Investigating an Incident

When you open an incident, you see:

• Incident summary and severity
• The triggering event (which action or error caused it)
• The agent and run involved
• Timestamp and current status

From there, you can navigate directly to the linked run to see the full event timeline and understand the complete context.

Link to Runs

Every incident links back to the specific run that triggered it. This is critical for investigation — you can trace the incident back to:

• What the agent was doing when the incident occurred
• What events preceded the problem
• What action was requested and what policy evaluated it
• The full data context available at the time

The Incident Console

The Incidents page in the sidebar shows all incidents across your workspace. Use it to:

• See open incidents sorted by severity and recency
• Filter by severity, agent, or status
• Click into an incident for the full detail view
• Track resolution progress

The console is designed for operators and admins who are responsible for keeping the system healthy.

Recommended Response Workflow

When an incident appears:

1. Assess severity. Critical incidents need immediate attention. Low severity can be batched for review.
2. Open the linked run. Review the event timeline to understand what happened.
3. Identify root cause. Was it a policy issue? A connector failure? An agent bug? Bad input data?
4. Take corrective action. This might mean updating a policy, fixing a connector, restarting the agent, or contacting the customer.
5. Resolve the incident. Mark it as resolved with a note about what was done.
6. Review and improve. If the incident reveals a systemic issue, update your policies or agent logic to prevent recurrence.

Resolving Incidents

Mark an incident as resolved when the underlying issue has been addressed. Include a resolution note describing what was done. Resolved incidents remain in the history for audit purposes.