Analyses
The session lifecycle, statuses, and what every analysis result contains
Analyses
An analysis is one diagnosis run. Every time someone clicks "Run
analysis", calls the API, runs /sigsentry analyze in chat, or has a
support ticket auto-triggered, a new analysis session is created.
Status lifecycle
| Status | Meaning |
|---|---|
pending | Created, queued for processing |
processing | Logs are being fetched and analyzed |
complete | A full diagnosis is available |
partial | Diagnosis is available but with caveats (e.g. logs were truncated) |
failed | Pipeline error; no diagnosis. The error is shown in the dashboard |
The dashboard updates the analysis view live while it's pending or
processing so you see status changes as they happen.
Inputs
Every analysis requires:
- Description (string, max 5,000 chars) — short statement of what's wrong. Doesn't need to be detailed, but more specific helps. "checkout 500s for users with stored cards" beats "checkout broken".
- Time window (
timeStart,timeEnd, ISO 8601) — when to look. Pick a window that contains the symptom; SigSentry only reads logs in this range - Screenshot (optional, image upload) — useful when the description is "look at the error in the screenshot"
Optional metadata can be attached as key-value pairs ({ user_id: "123" })
and is included in the API request and audit trail.
What an analysis result contains
A successful analysis returns:
- Summary — one paragraph explaining what happened
- Severity + confidence percentage
- Root cause — service, error type, category (deploy regression, external dependency timeout, configuration drift, etc.)
- Affected services — each with a role:
- origin — where the error started
- propagator — passed it along
- affected — degraded as a result
- Timeline — chronological log events; root-cause events are flagged
- Suggested actions — prioritized list, each tagged as
fix/mitigate/investigate/escalate - Code correlation (when a repo is connected) — file, function, line range, and likely PR
- Logs scanned — how many log lines were considered
Postmortems
After an analysis is complete, the dashboard has a Generate Postmortem button. This produces a Markdown writeup ready to drop into your incident management tool:
- Plain template generation is available on Starter+
- AI-polished postmortems are a Pro+ feature — the template is rewritten into a more polished narrative by our AI model
Follow-up questions
After an analysis, anyone with analysis:create permission can ask a
follow-up question on it. Follow-ups thread under the original analysis;
when triggered from chat, they post back into the same chat thread.
Feedback
Analysis results have a feedback widget — correct, partially correct, incorrect, with optional comment. This feeds your team's
quality metrics and helps tune the analysis prompts over time.
Quotas and overage
Each tenant has a monthly analysis quota based on plan tier. Overage — analyses run after the quota — is opt-in per billing cycle, charged at a per-analysis overage rate. See Plans & quotas for current numbers and Overage for how to opt in.