--- title: "Admin Get Session" method: GET path: "/admin/sessions/{session_id}" --- # Admin Get Session `GET /admin/sessions/{session_id}` ## Path parameters - `session_id` string, required ## Response `200` Successful Response - AdminGetSessionResponse — Response for admin_get_session endpoint. - `session_id` string, required - `incident_description` string, nullable, required - `incident_timezone` string, nullable, required - `incident_time` string, nullable, required - `messages` AdminSessionChatMessage[], required - `session_id` string, nullable, required - `chat_id` string, nullable, required - `message_type` 'user' | 'assistant' | 'system' | 'investigation' | 'unknown' | 'tool', required - `content` string, nullable, required - `content_parsed` union, required - ContentParsed — Parsed content is the parsed content of the user's question. Attributes: answer: The ContentAnswer for RCA responses (V1 schema). answer_v2: The ContentAnswerV2 for RCA responses (V2 timeline-based schema). explore_answer: The FastAnswer for chat mode responses. structured_follow_up_answer: The FastAnswer for structured follow-up responses. - `answer` ContentAnswer — Content answer is the answer to the user's question. Attributes: candidate_issues: The candidate issues that the LLM has identified as a potential issue. summary_of_report: The summary of the report. - `candidate_issues` CandidateIssue[] — Focus on getting 2-3 candidate issues. However, if there are no likely root causes, just explain why it is not possible to identify a root cause in 'summary_of_report' and return an empty list for 'candidate_issues'. If there are no anomalous events, return an empty list. Your strongest root cause should be the first one in the list, the second strongest should be the second one in the list, etc. - `candidate_issue_id` string, nullable — A uuidv4 that you generate randomly. Should be unique for each candidate issue. - `events` CandidateEvent[], required — List of events following the structure of 'What', 'Where', and 'Why'. The first event should describe the observed symptom. Subsequent events should explain the 'why' behind the previous event. Each event MUST ALWAYS have one or more graph_ids for support. - … - `title` string, required — Short title describing the strongest root cause candidate - `root_cause_summary` string, required — Summary of the root cause candidate at most 5 sentences - `confidence` string, required — 'High', 'Medium', or 'Low' - `confidence_explanation` string, required — Explain your choice of confidence level in a short sentence. - `highlights` string[] — Salient phrases or words that you think are important to the root cause. For example, if you can say something more high level such as 'network issue', 'database issue', etc. - `candidate_issue_services` string[], nullable — List of 3-5 services that are relevant to the candidate issue. This is a subset of the full service graph. The purpose is to help with visualizing the system around the candidate issue. Always err on the side of including more services, not less. Only return an empty list if there are truly NO services that are relevant. - `summary_of_report` union — List of 3-5 bullet points with clear findings, prioritize cause-effect relationships. Each bullet point should be a concise statement without labels (no 'Impact:', 'Root Cause:', etc.). Focus on the analysis, especially your root causes, the symptoms that led you to your answer, and what the total system impact is. If you mention a specific service as being problematic, make sure to describe what the service does and why it could be problematic. - string - string[] - `report_summary` string, nullable - `get_traces_request` GetTracesRequest - `trace_requests` TraceRequest[], required - … - `start_time` string, required - `end_time` string, required - `markdown_report_summary` string, nullable — Markdown document with clear findings, prioritizing cause-effect relationships. It should be short enough to display in a slack channel. ## Evidence Citations Tool responses contain evidence items with simple IDs (E_ prefix + 10 letters, e.g. E_toqisenalu). Cite them directly using filled citation tags. - Do not reference the internals of the filesystem data storage or how the data was collected. ### Citation Format To cite evidence, place a citation tag immediately after the claim it supports: ``` ``` Rules: - Use double quotes for ID strings inside the JSON array: `ids='["E_id1", "E_id2"]'` - The content between `` and `` must always be empty — no text inside - Every opened `` tag must be closed with `` - Only cite IDs you actually observed in tool responses. Do not fabricate citations. - When uncertain, omit — wrong citations are worse than no citations - For each claim, verify the ID actually contains the data you are referencing ### Time Range Attributes When citing time-series evidence (metrics, panels) and the surrounding text discusses a specific time window, add timeRangeStart and timeRangeEnd attributes with ISO 8601 timestamps: ``` ``` Only include time range attributes when the text references a specific sub-range of the data. Omit when citing the evidence as a whole. ### Citation Examples **In lists:** ```markdown - API latency increased to 2.5 seconds ``` **In tables:** ```markdown | Service | Error Rate | Evidence | |---------|-----------|----------| | payment-api | 45% | Connection pool exhaustion in logs | | checkout-service | 67% | Timeout errors and failed transactions | ``` **In paragraphs:** ```markdown The payment service experienced a 45% error rate increase. This correlated with database connection pool exhaustion. ``` **With time range (for time-series data):** ```markdown CPU usage spiked to 95% between 14:00 and 14:30. ``` ## Table Formatting Rules IMPORTANT: Table cells must not contain styled text. Do not use the following inside table cells: - Bold: **text** or __text__ - Italic: *text* or _text_ - Strikethrough: ~~text~~ - Inline code: `text` Markdown links [text](url) are allowed in table cells. - `slack_report` SlackReport — Rendering type for Slack-specific report fields. markdown_report_summary is always a non-empty str. The default "" is intentional: BeforeValidator coerces null DB values to "", and ContentAnswerV2._backfill_slack_report_markdown then fills it from the top-level markdown_report_summary so the rendered value is never blank. slack_report_markdown and slack_report_blocks back the variant-B / variant-C A/B test of alternate Slack rendering paths. Empty / None means "agent didn't emit this variant" — the posting path branches on truthiness to decide whether to post the variant message. - `thread_starter` string, nullable - `markdown_report_summary` string - `slack_report_markdown` string - `slack_report_blocks` union[], nullable - … - `answer_v2` ContentAnswerV2 — RCA report structure with timeline-based analysis. - `markdown_report_summary` string, required - `slack_report` SlackReport, required — Rendering type for Slack-specific report fields. markdown_report_summary is always a non-empty str. The default "" is intentional: BeforeValidator coerces null DB values to "", and ContentAnswerV2._backfill_slack_report_markdown then fills it from the top-level markdown_report_summary so the rendered value is never blank. slack_report_markdown and slack_report_blocks back the variant-B / variant-C A/B test of alternate Slack rendering paths. Empty / None means "agent didn't emit this variant" — the posting path branches on truthiness to decide whether to post the variant message. - `thread_starter` string, nullable - `markdown_report_summary` string - `slack_report_markdown` string - `slack_report_blocks` union[], nullable - … - `teams_report` TeamsReport — Rendering type for Microsoft Teams-specific report fields. ``adaptive_card_body`` is the Teams analogue of ``SlackReport.slack_report_blocks``: the LLM-emitted body of an Adaptive Card (a list of element objects). Empty / None means the agent didn't emit one — the posting path then falls back to rendering the neutral markdown into a single text block. - `adaptive_card_body` object[], nullable - … - `condensed_markdown_report_summary` string - `title` string, nullable - `preview_text` string, nullable - `summary_of_report` union - string - string[] - `mitigation_strategy` string, nullable - `timeline` TimelineEventV2[], nullable - `id` string, required — Unique identifier for this timeline event. Used to reference this event as the key_signal_id. Generate a short unique ID (e.g., 'evt_1', 'evt_2'). - `description` string, required — 1-2 sentences (max 3) explaining what this evidence shows and why it matters. Be descriptive and specific. Example: 'The payment-api pod restarted due to OOMKilled after memory usage reached 2.1GB, triggering downstream timeout errors in the checkout flow.' - `evidence_id` string, required — ID of the evidence item that supports this event. Each event maps to exactly one piece of evidence. - `timestamp` string, required — ISO 8601 timestamp when this event occurred (e.g., '2024-01-15T10:30:00+00:00'). If the evidence has a specific EVIDENCE TIMESTAMP (not 'TIME_SERIES_ANALYSIS_REQUIRED'), copy that exact timestamp. If the EVIDENCE TIMESTAMP is 'TIME_SERIES_ANALYSIS_REQUIRED', you must analyze the time series data (metrics, panels, etc.) to identify the most relevant timestamp (e.g., anomaly peak, spike start, threshold breach). - `time_range_start` string, nullable — Optional ISO 8601 start of the relevant time window within the evidence. Set when the evidence is time-series data and this event references a specific sub-range (e.g., a spike from 14:00 to 14:30). Omit when the whole evidence item is relevant. - `time_range_end` string, nullable — Optional ISO 8601 end of the relevant time window within the evidence. Must be set together with time_range_start. - `key_signal_id` string, nullable - `key_signal_summary` string, nullable - `confidence_explanation` string, nullable - `confidence` 'High' | 'Medium' | 'Low', nullable - `needs_escalation` NeedsEscalation — Indicates whether an incident needs escalation to users. This flag signifies whether an event is significant enough to be surfaced to users downstream. Attributes: value: Whether the incident needs escalation. explanation: Explanation for the escalation decision. - `value` boolean, required — Whether the incident needs escalation. - `explanation` string, required — Brief explanation for the escalation decision, including key factors considered. - `explore_answer` FastAnswer — Follow up response is the response to the user's question. summary: The summary of the response as a list of bullet points. summary_list: Alias for summary for backwards compatibility. highlights: The highlights of the response. evidence_blocks: The evidence blocks of the response. slack_report_markdown / slack_report_blocks: Slack rendering A/B test variants populated by a post-processing LLM call when SLACK_RENDERING_AB_TEST is on. See [[SlackReport]] for the analogous RCA fields. - `summary` string, required — Concise summary of the response — match length to the question per the voice guidance in the system prompt. This is for backwards compatibility and will be deprecated in the future. - `summary_list` string[], nullable — Summary of the response as a list of bullet points (2-5 items) summarizing your analysis and findings - `highlights` string[], required — List of key phrases, service names, or words that are to be highlighted in the response and surface in the UI. - `evidence_blocks` EvidenceBlock[], required — List of up to 3 evidence blocks for citations in the response. If there are no anomalous events, return an empty list for this field. - `text` string, required — Up to 3 sentences to summarize the evidence to support the key findings. - `evidence_ids` string[], required — List of up to 2 evidence UUIDs referenced in this block. - `slack_report_markdown` string - `slack_report_blocks` object[], nullable - `structured_follow_up_answer` FastAnswer — Follow up response is the response to the user's question. summary: The summary of the response as a list of bullet points. summary_list: Alias for summary for backwards compatibility. highlights: The highlights of the response. evidence_blocks: The evidence blocks of the response. slack_report_markdown / slack_report_blocks: Slack rendering A/B test variants populated by a post-processing LLM call when SLACK_RENDERING_AB_TEST is on. See [[SlackReport]] for the analogous RCA fields. - `summary` string, required — Concise summary of the response — match length to the question per the voice guidance in the system prompt. This is for backwards compatibility and will be deprecated in the future. - `summary_list` string[], nullable — Summary of the response as a list of bullet points (2-5 items) summarizing your analysis and findings - `highlights` string[], required — List of key phrases, service names, or words that are to be highlighted in the response and surface in the UI. - `evidence_blocks` EvidenceBlock[], required — List of up to 3 evidence blocks for citations in the response. If there are no anomalous events, return an empty list for this field. - `text` string, required — Up to 3 sentences to summarize the evidence to support the key findings. - `evidence_ids` string[], required — List of up to 2 evidence UUIDs referenced in this block. - `slack_report_markdown` string - `slack_report_blocks` object[], nullable - FastAnswer — Follow up response is the response to the user's question. summary: The summary of the response as a list of bullet points. summary_list: Alias for summary for backwards compatibility. highlights: The highlights of the response. evidence_blocks: The evidence blocks of the response. slack_report_markdown / slack_report_blocks: Slack rendering A/B test variants populated by a post-processing LLM call when SLACK_RENDERING_AB_TEST is on. See [[SlackReport]] for the analogous RCA fields. - `summary` string, required — Concise summary of the response — match length to the question per the voice guidance in the system prompt. This is for backwards compatibility and will be deprecated in the future. - `summary_list` string[], nullable — Summary of the response as a list of bullet points (2-5 items) summarizing your analysis and findings - `highlights` string[], required — List of key phrases, service names, or words that are to be highlighted in the response and surface in the UI. - `evidence_blocks` EvidenceBlock[], required — List of up to 3 evidence blocks for citations in the response. If there are no anomalous events, return an empty list for this field. - `text` string, required — Up to 3 sentences to summarize the evidence to support the key findings. - `evidence_ids` string[], required — List of up to 2 evidence UUIDs referenced in this block. - `slack_report_markdown` string - `slack_report_blocks` object[], nullable - `input` string, nullable, required - `full_output` string, nullable, required - `parsed_output` string, nullable, required - `artifacts` ChatMessageArtifact[], required - `chat_id` string, required - `session_id` string, required - `tool_call_id` string, required - `artifact_types` string[], required - `created_at` string, nullable, required - `triage_content` string, nullable, required - `triage_content_parsed` TriageContentParsedV2, required — Parsed Alert Triage V2 report content with question-based narrative structure. This model wraps the V2 triage report answer which provides a guided investigation narrative — less "what," more "why" and "so what." The format follows the SRE reasoning chain and enables rapid triage decisions (under 30 seconds) by structuring findings around diagnostic questions rather than data types. The report structure is stable across customers, but content is dynamic based on available data. This allows the AI to produce consistent, explainable narratives across all alert types while adapting to data richness. Attributes: answer: The V2 triage report with question-based findings following the SRE reasoning chain evidence: Raw evidence data from observability platforms structured_follow_up_answer: The FastAnswer for structured follow-up responses - `answer` TriageReportAnswerV2 — Alert Triage V2 report with question-based narrative structure. This format organizes triage findings as a guided investigation narrative — **less "what," more "why" and "so what."** Instead of grouping by data types (logs, metrics), findings are structured around diagnostic questions that mirror how SREs reason during troubleshooting. The report follows the natural SRE reasoning sequence: 1. What triggered this alert? (Symptom/Detection) 2. What else changed around the same time? (Correlated Factors) 3. Who or what was affected? (System Impact) 4. What could have caused it? (Related Changes) 5. Has this happened before? (Context/History) 6. What should I do next? (Recommendation) This structure enables engineers to make triage decisions in under 30 seconds by providing a compact, readable, and consistent narrative that answers: "what happened, what else changed, who was affected, and what should I do?" Attributes: report_summary: Brief TL;DR (3 sentences max) with state awareness (recovered/ongoing/intermittent), key metrics, and outcome priority_confidence: Confidence score reflecting evidence strength priority_confidence_explanation: Actionable explanation of the priority confidence finding_summaries: 3-5 findings following the SRE reasoning chain with question-based structure service_impact_summary: Quantified impact on services and users with specific numbers service_impact_summary_evidence: Evidence linking to impact statements highlights: Key service/resource names for UI highlighting (specific names only) - `report_summary` string, required — Brief TL;DR limited to 3 sentences max: (1) what happened with explicit state awareness (recovered/ongoing/intermittent) and time window, (2) most important symptoms with key metrics (error rate, latency, volume, duration), (3) outcome/current status. Answers 'what happened and so what?' in narrative style. - `priority_confidence` number, required — Confidence score 0-10: 8-10 (multiple correlated evidence sources, clear causality), 5-7 (supporting evidence with some gaps), 0-4 (suggestive patterns only, significant unknowns) - `priority_confidence_explanation` string, required — Specific, actionable explanation of the priority_confidence score based on evidence quality, completeness, and impact observed. Examples: 'Multiple correlated evidence sources confirm consumer lag issue', 'Evidence suggests transient issue with recovery', 'Limited evidence of impact, monitor for recurrence' - `finding_summaries` FindingSummary[] — 3-5 findings following the SRE reasoning chain (symptom → correlated factors → impact → causes → history → recommendation). Each finding answers a diagnostic question with 1-3 short, declarative bullet points that quantify deviations, include chronological hints, and merge tightly related signals. Skip questions if no relevant data available. - `question` string, required — Diagnostic question from the SRE reasoning chain: 'What triggered this alert?', 'What else changed around the same time?', 'Who or what was affected?', 'What could have caused it?', 'Has this happened before?', or 'What should I do next?' - `answer_list` string[] — List of 1-3 short, declarative bullet points answering the question. Each bullet should be concise and focused on a single fact or tightly related group of facts. Quantify deviations ('3× baseline', '15% drop'), add chronological hints when relevant ('8m earlier', 'before the spike'), and merge tightly related signals into single bullets. Use past tense for recovered alerts, present tense for ongoing. Avoid speculation unless confidence is low. Keep bullets readable (typically one sentence each, occasionally two if tightly related). - `evidence_ids` string[] — List of UUIDs of raw evidence from metrics, logs, alerts, etc. - `service_impact_summary` string[] — Bullet points with quantified impact (request volumes, error counts, affected services/operations, SLO/burn rate status). Include specific numbers and explicit state awareness (recovered/ongoing). Example: 'Service: payments-api, Volume: 200 requests/sec failing, Burn rate: 10x normal' - `service_impact_summary_evidence` ServiceImpactSummaryEvidenceV2[] — Evidence linking impact statements to specific metrics, logs, or alerts via UUIDs. Each entry connects 1-3 evidence items to an impact claim. - `evidence_ids` string[] — List of UUIDs of raw evidence - `evidence_description` string, required — Bullet point summary of the evidence - `highlights` string[] — Specific service names, resource names, operation names, region names, or key tag values to highlight in UI. Use exact names from the system, NOT generic terms like 'database' or 'Redis'. Single tokens or system-specific multi-word phrases only. - `evidence` unknown[], nullable - unknown - `structured_follow_up_answer` FastAnswer — Follow up response is the response to the user's question. summary: The summary of the response as a list of bullet points. summary_list: Alias for summary for backwards compatibility. highlights: The highlights of the response. evidence_blocks: The evidence blocks of the response. slack_report_markdown / slack_report_blocks: Slack rendering A/B test variants populated by a post-processing LLM call when SLACK_RENDERING_AB_TEST is on. See [[SlackReport]] for the analogous RCA fields. - `summary` string, required — Concise summary of the response — match length to the question per the voice guidance in the system prompt. This is for backwards compatibility and will be deprecated in the future. - `summary_list` string[], nullable — Summary of the response as a list of bullet points (2-5 items) summarizing your analysis and findings - `highlights` string[], required — List of key phrases, service names, or words that are to be highlighted in the response and surface in the UI. - `evidence_blocks` EvidenceBlock[], required — List of up to 3 evidence blocks for citations in the response. If there are no anomalous events, return an empty list for this field. - `text` string, required — Up to 3 sentences to summarize the evidence to support the key findings. - `evidence_ids` string[], required — List of up to 2 evidence UUIDs referenced in this block. - `slack_report_markdown` string - `slack_report_blocks` object[], nullable - `created_by_user_id` string, nullable, required ## Other responses - `422` — Validation Error --- [API](https://skmtc.net/traversal/apis/fastapi.md) · [All operations](https://skmtc.net/traversal/apis/fastapi/llms.txt) · [OpenAPI document](https://skmtc-service-staging.skmtc.workers.dev/v1/apis/traversal/fastapi/revisions/2134ebffd1ef/schema)