Incident postmortem diagrams in Slack
Map a confirmed incident flow, distinguish observations from hypotheses, and review the diagram and follow-up changes with your team.
Explain the confirmed failure path before designing the fix
After a checkout incident, the review needs to distinguish what happened from what you intend to change. Arialine can help represent the flow your team supplies and keep subsequent diagram changes attached to their requests. It is not an incident detector or root-cause oracle.
Illustrative observations
- 09:02
Payment accepted - 09:03
Worker request failed - 09:10
Manual retry completed
Build from checked facts
Supply the flow and mark what remains unknown
@Arialine map the confirmed checkout incident: payment succeeded, fulfillment request failed, a manual retry completed. Label the cause of the worker failure as unknown.
Review source logs and observations yourself. Include only authorized context. Do not ask the diagram to infer a cause from missing evidence.
Keep observations separate from proposed prevention
Payment succeeded; fulfillment failed
Preserve this incident explanation before changing the design. These timestamps and source are illustrative, not imported incident data.

Publish the learning, not just the picture
Incident record
Retain impact, observations, remaining uncertainty and contributing factors in your team's postmortem.
Follow-up ownership
Assign implementation and verification in your existing work system. Arialine does not create or synchronize those tickets automatically.
Reviewed diagram
Link the checked diagram version and its source discussion from the incident record.
Shared Markdown
A supported Markdown write-up can become a native Slack Canvas with Mermaid images. This is conversion, not a two-way incident-document sync.
Workflow reference: Google SRE on incident learning.
Take the next step
Try one real team workflow
Install in an approved workspace, invite Arialine to the channel, create a small board and review one addressed revision.
