Issues & Root Cause Analysis

Overview

Monitors & Alerts: Categories, Triggers & Notifiers covers how a Monitor's Trigger fires and creates an Issue in the first place. This page picks up from there: what an Issue is, how to review and filter Issues in the Dashboard, how to run AI-powered root cause analysis on one, and the resolution workflow to take it from first alert to closed.

Go to Issues in the Dashboard sidebar to see every issue your monitors have raised. Each issue tracks the monitor and trigger that fired, the evaluation window it was detected in, the total calls evaluated against the affected calls count, and its alert delivery status.

Every issue has one of three statuses:

You can filter the Issues list by status to, for example, see only New issues that still need triage, or only In Progress issues your team is actively working.

Via the Dashboard

1. Go to Issues in the sidebar and select the issue you want to investigate.
2. Click the Analyze button in the issue detail panel.
3. Review the summary, root cause, impact assessment, and suggestions once the analysis completes.

Via the API

The same analysis is available as an endpoint that takes only the issue ID as a path parameter and your API key for authorization — no request body needed:

curl -X POST "https://api.sulus.ai/monitoring/issue/e5f6a7b8-c9d0-1234-efab-567890123456/analyze" \
  -H "Authorization: Bearer $CORE_SYSTEM_API_KEY"

A root cause analysis response has four sections:

Here's a full example response:

{
  "summary": "12 calls failed due to LLM provider timeouts during peak hours, affecting 8% of total call volume in the evaluation window.",
  "rootCause": {
    "category": "timeout",
    "explanation": "The model provider consistently timed out during the 9:30-10:30 AM window, likely due to increased traffic during peak business hours. The default timeout of 10 seconds was insufficient for the model's response latency during this period.",
    "confidence": "high"
  },
  "impact": {
    "severity": "high",
    "description": "Users experienced call drops mid-conversation when the LLM failed to respond within the timeout window.",
    "affectedCalls": 12,
    "failureRate": 0.08
  },
  "suggestions": [
    {
      "title": "Increase LLM timeout",
      "description": "Raise the model request timeout from 10 seconds to 20 seconds to accommodate peak-hour latency.",
      "priority": "high",
      "configExample": "{ \"model\": { \"provider\": \"openai\", \"timeout\": 20000 } }"
    }
  ]
}

Failures surfaced this way often line up with a specific endedReason value on the affected calls — see Ended Reason: Complete Reference if you want to cross-check the exact failure pattern against the call records directly.

Once an issue lands in the Dashboard, work it through to close in this order:

1. Review the issue details and what triggered it — the monitor, the trigger threshold, and the evaluation window.
2. Run root cause analysis (Dashboard Analyze button or the /monitoring/issue/{issueId}/analyze endpoint) to get a summary, root cause, impact assessment, and suggestions.
3. Acknowledge the issue by marking it In Progress so your team knows it's being worked.
4. Apply the suggested fix from the analysis — or your own fix, if the suggestions don't fully cover it.
5. Mark Resolved once you've confirmed the underlying problem is fixed.

In summary: an Issue tells you something crossed a threshold, root cause analysis tells you why, and the New → In Progress → Resolved status flow keeps your team's response to it visible and accountable. See Monitors & Alerts: Categories, Triggers & Notifiers for how the Monitor and Trigger that created the issue are configured in the first place.