Incident Triage — example output

███╗ ██╗ ██████╗ ██╗ ██╗ █████╗ ██╗ ██╗ ██╗██╗████████╗ ████╗ ██║██╔═══██╗██║ ██║ ██╔══██╗██║ ██║ ██╔╝██║╚══██╔══╝ ██╔██╗██║██║ ██║██║ █╗ ██║ ███████║██║ █████╔╝ ██║ ██║ ██║╚████║██║ ██║██║███╗██║ ██╔══██║██║ ██╔═██╗ ██║ ██║ ██║ ╚███║╚██████╔╝╚███╔███╔╝ ██║ ██║██║ ██║ ██╗██║ ██║ ╚═╝ ╚══╝ ╚═════╝ ╚══╝╚══╝ ╚═╝ ╚═╝╚═╝ ╚═╝ ╚═╝╚═╝ ╚═╝ ✦ NowAIKit — The #1 AI App for ServiceNow - Running ops-triage in direct mode (ollama)... ``` INCIDENT TRIAGE REPORT ======================= Incident: [NOT PROVIDED - DEMO DATA] | Priority: [PENDING] | State: [UNKNOWN] ⚠️ DATA LIMITATION NOTICE ------------------------- The CMDB CI data provided appears to be from the demo2 instance but is incomplete and lacks critical incident context: - No incident number provided - No affected CI details beyond generic "Unknown" catch-all CI - No SLA information available - No change history or incident timeline - JSON data appears truncated (incomplete records) To provide an accurate triage, I need the following additional data: - Incident table (incidence) record with incident number - Incident description and state - Affected Configuration Item (CI) reference - SLA definitions attached to the incident - Change records for the past 7 days - Knowledge base matches for similar issues === WORKING WITH AVAILABLE DATA === Based on the CMDB CI data provided, here is what can be analyzed: INCIDENT TRIAGE REPORT ======================= Incident: [INCIDENT #NOT_YET_SPECIFIED] | Priority: [ASSIGN_TO_INCIDENT] | State: [OPEN] IMPACT ASSESSMENT Affected CI: Unknown (cmdb_ci - catch-all reference) Business Services: [UNKNOWN - requires incident CI mapping] Upstream Dependencies: 0 CIs (no dependencies tracked on Unknown CI) Downstream Dependants: 0 CIs (Unknown CI is orphan reference) Estimated User Impact: 0 users (requires incident impact data) CMDB ANALYSIS FINDINGS - CI Class: cmdb_ci (generic Configuration Item) - Operational Status: 1 (operational) - Discovery Source: [EMPTY] - Attestation Status: false - Fault Count: 0 NOTE: The first record shown is the "Unknown" CI reference CI that ServiceNow creates as a catch-all for duplicate CI relationships after platform upgrades. This is a reference item, not a production CI affecting users. - Recommendation: Verify actual incident CI via: get_incident(incident_number) to get affected CI references get_incident_related_cis() to map impacted infrastructure SLA STATUS Response SLA: [DATA_MISSING] Resolution SLA: [DATA_MISSING] NOTE: SLA data requires: - incident_state = open - incident priority (P1/P2) to trigger SLA rules - Active SLA records from list_active_slas ANALYSIS Root Cause Hypothesis: [CANNOT DETERMINE - incident details missing] Evidence: - CMDB data is incomplete/truncated - No incident-specific error logs or diagnostics available - No change request history to correlate with incident window - No knowledge base articles without specific CI/symptom Related Changes: [NO CHANGE DATA PROVIDED] KB Matches: [NO KB SEARCH DATA PROVIDED] RECOMMENDED ACTIONS 1. [CRITICAL] - Provide incident number for full triage 2. [CRITICAL] - Submit complete incident data via get_incident() 3. [HIGH] - Map affected CI to business service via cmdb_ci → cmdb_business_service 4. [HIGH] - Run list_active_slas() to assess SLA compliance 5. [MEDIUM] - Search change_request for recent changes to affected CIs 6. [MEDIUM] - Query kb_knowledge for error message/symptom matches 7. [MEDIUM] - Use get_incident_timeline() for incident history NEXT STEPS FOR USER ------------------- To proceed with full incident triage, please provide: 1. Incident Number (inc_number) 2. Incident description 3. Affected CI sys_id and name 4. Incident priority and state 5. SLA definition (if custom) 6. Error messages or symptoms 7. Time of incident occurrence Once provided, I will execute full triage including: - Complete impact assessment via CMDB relationships - SLA breach analysis - Knowledge base search - Change history correlation - Resolution recommendations ... (6 more lines — full output truncated for screenshot)