Fix the incident first,the postmortem is half-written
The worst time to write a postmortem is three days later, from memory, with the error dialogs long gone. Khint collects the evidence while you work (screen captures of the errors, the incident ticket, the war-room thread) into one local working context, then drafts the writeup with a single AI action and pushes it to Confluence.
Postmortems fail at the evidence stage,
not the writing stage
Everyone can write “what went wrong” prose. What makes a postmortem useful (an honest timeline, the exact error text, what was decided in the heat of it) is exactly what evaporates once the service is back up: dialogs closed, threads buried, terminal scrolled away. Khint sits behind one palette shortcut, and its three pillars (Agents, Capture, and Memory) turn evidence collection into a keystroke you can afford mid-incident, so the writeup afterwards is assembly, not archaeology.
From pager to published postmortem in five moves
Every step runs from the same palette shortcut.
Start a session the moment the pager goes off
Open a Memorysession named after the incident: “Checkout failing, 14:00”. From this point on, every capture, pull and draft is collected into one local, timestamped context. That is the difference between reconstructing the timeline on Friday and having it already written down.
Capture the evidence while it's on screen
Error dialogs and log panes vanish when someone restarts the service. The palette's Extract text row grabs any region of the screen and turns it into text. Capturecopies it to your clipboard and logs it into the session. Facing a stack trace you don't recognise? Capture & ask opens a chat about the screenshot, and the exchange is logged too.
Pull the paper trail in beside it
Run Pull issue on the incident ticket and Pull thread on the Slack war-room. With Jira and Slack connected on the Integrationspage, both are palette rows, and each pull lands as an entry in the same session. The pull rows are off by default to keep the palette lean; switch on the ones you use from each integration's card.
Draft the postmortem with one Action
Once the fire is out, type five rough bullets about what happened, select them, and run a saved Actionlike “Draft incident postmortem”. Because the Action reads the active session, the draft is grounded in the captured errors, the ticket and the thread (impact, timeline, root cause, follow-ups), not in what you can still recall after six hours of firefighting.
Publish it and close the loop
The palette's Create page row pushes the writeup to Confluence, Add comment drops the link and outcome onto the incident ticket, and Change status moves it to done. Follow-up actions from the postmortem become tickets the same way your meeting notes become Jira tickets.
The timeline was kept for you, as you worked
This is a different job from turning one error screenshot into a bug ticket at detection time, and from the team-process sprint retrospective at the end of a sprint. A postmortem is an after-the-fact document that lives or dies on evidence collected during the event, and that is precisely what a Memory session holds. The same session that fed the draft also carries the pulled Slack thread and the ticket history, so follow-up questions in the review meeting get answered from the log, not from recollection.
Common questions
What does Khint actually collect during an incident?
Only what you deliberately put in. Each Extract text capture, each Capture & ask exchange, each Jira issue or Slack thread you pull lands as an entry in the active Memory session, and the session keeps a compacted running summary of them. There is no background recording and no always-on capture: if you didn't press the shortcut, nothing was logged. Sessions live in a local database on your machine and are never synced to the cloud, which matters when the incident involves a customer's data or an embarrassing root cause.
How does the AI know what to put in the postmortem?
Through Memory. While a session is active, every Action you run reads the session's compacted context alongside the text you selected. So a postmortem-drafting Action isn't working from your memory of the outage. It is working from the error text you captured at 14:02, the incident ticket you pulled, and the war-room thread you brought in. The template is yours too: the Action's prompt is where you spell out the sections you want (impact, timeline, root cause, follow-up actions), and Khint can draft that prompt for you from a one-line description.
Can the finished postmortem land in Confluence and on the ticket?
Yes. With Atlassian connected, the palette's Create page row pushes text to Confluence as a new page, and the Add comment and Change status rows let you close the loop on the incident ticket itself. Each write is logged back into the session as well. If you run incidents regularly, bundle the drafting Action and a Confluence page step into a saved workflow, so the next postmortem is a single run instead of four moves.
There are customer emails and IDs in our logs. Do those go to the AI?
Two protections. First, an Action only ever sends the text you selected plus the session's compacted summary, never your whole screen or disk. Second, any Action can opt in to Redact PII, which replaces email addresses, phone numbers and account identifiers with placeholders before the text is processed. And because the full bodies of your captures and results stay in the local database, the unredacted evidence never leaves the machine as a side effect.
Never reconstruct a timeline from memory again
Free with 10 AI actions and 5 captures per day. No credit card. Sessions stay in a local database on your machine.