Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/nicolas344/Sentinel-SoftServe/llms.txt

Use this file to discover all available pages before exploring further.

When an incident reaches resolved status, Sentinel automatically generates a structured post-mortem document using GPT-4o-mini. The generation happens asynchronously as a FastAPI BackgroundTask so it never blocks the status update that the frontend receives in real time. Engineers can then review, edit, and export the post-mortem directly from the dashboard’s Post-Mortem tab.

​
Generation Lifecycle

1

Incident resolves

The verification service confirms the affected resource is healthy and sets status = 'resolved', writing the resolved_at timestamp. The MTTR is computed as resolved_at - created_at and formatted as a human-readable string (e.g., 4m 32s, 1h 12m).
2

BackgroundTask triggers

The FastAPI route handler schedules post-mortem generation as a background task immediately after committing the status update. This is non-blocking — the HTTP response is already on its way to the frontend before the LLM call starts.
# Conceptual FastAPI pattern used in Sentinel:
background_tasks.add_task(generate_post_mortem, incident_id)
3

LLM generates the document

GPT-4o-mini receives the full incident context as a JSON prompt:
  • title, severity, target, source_type
  • Container or query logs (truncated to 2,500 chars)
  • agent_reasoning (full investigation Markdown, truncated to 3,500 chars)
  • Status timeline extracted from incident_events
  • action_result and action_error
  • Computed MTTR
The model returns a structured Markdown document. If no OpenAI API key is configured, a deterministic fallback template is used instead.
4

Engineer reviews in the Post-Mortem tab

The PostMortemEditor component fetches the content via GET /api/incidents/{id}/post-mortem when the Post-Mortem tab is first opened. The content appears in a full-height Markdown textarea. The last-updated timestamp and character count are shown in the header.
5

Edit if needed

The textarea is fully editable. Engineers can correct inaccuracies, add context, rewrite the lessons-learned section, or attach links to follow-up tickets. All edits are local until saved.
6

Save and export

Click Save to persist changes via PUT /api/incidents/{id}/post-mortem. Click Export .md to download the current content as a Markdown file named postmortem_<title>.md — no save required before export.

​
Post-Mortem Structure

The LLM is prompted to produce a Markdown document using the following fixed sections (defined in services/postmortem/template.py):
SectionContents
SummaryA concise description of the incident drawn from logs and agent reasoning
Root CauseThe agent’s diagnosis of the underlying failure
TimelineChronological status transitions sourced from incident_events
ResolutionThe exact command executed and its output, or the manual resolution applied
MTTRresolved_at - created_at formatted as a human-readable duration
Lessons LearnedObservations and recommendations to improve observability and runbooks
Preventive ActionsConcrete steps (alerts, capacity review, runbook updates) to avoid recurrence
For incidents resolved manually — where the agent never executed a command — you can still trigger generation by opening the Post-Mortem tab. GET /api/incidents/{id}/post-mortem re-generates the document on demand if the stored content is empty, using whatever incident context is available.

​
The PostMortemEditor Component

The PostMortemEditor renders only when incident.status === 'resolved'. For incidents still in progress it shows a message explaining that the post-mortem will be generated automatically upon resolution. 
// Loading state — shown while fetching from the API:
// "Generating post-mortem..." spinner

// Ready state — the full editable textarea:
<textarea
  value={content}
  onChange={(e) => setContent(e.target.value)}
  className="... min-h-[520px] font-mono ..."
/>
The component header displays:
  • Last updated — formatted date/time of the most recent save
  • Character count — locale-formatted length of the current content
  • Export .md button — triggers a browser download of the raw Markdown
  • Save button — disabled while loading, while saving, or if the content is empty

​
API Reference

MethodEndpointDescription
GET/api/incidents/{id}/post-mortemFetch the post-mortem. Re-generates if content is empty.
PUT/api/incidents/{id}/post-mortemSave edited content. Body: { "content": "..." }
Both endpoints require a valid Supabase Bearer token in the Authorization header. The PUT response includes an updated_at timestamp that the PostMortemEditor uses to refresh the header metadata without a full reload.

​
ChromaDB Storage

After a post-mortem is generated, Sentinel stores the full incident record (including agent_reasoning, proposed_action, and the post-mortem text) in ChromaDB under the incidents-{domain} collection. This enables the SimilarIncidentsCard to surface this incident when future incidents with similar patterns are investigated — closing the learning loop across incidents.

​
Export via ExportModal

The Export Incident button (accessible from the detail panel header) opens the ExportModal, which includes the complete post-mortem content in both the JSON and Markdown export formats. This makes it easy to attach post-mortems to tickets, share them in Slack, or archive them in a runbook repository. 
// JSON export excerpt:
{
  "post_mortem": "# Post-Mortem: nginx-prod High Error Rate\n\n## Summary\n..."
}

Build docs developers (and LLMs) love

Get started for freeTalk to us