Incident reviewers and service owners

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.
1Build from checked facts

Supply the flow and mark what remains unknown

Review source logs and observations yourself. Include only authorized context. Do not ask the diagram to infer a cause from missing evidence.

Working in a dedicated incident channel? Invite Arialine there and type /arialine: the board is posted as a top-level message in that channel, with its versions in the board thread. Run /arialine updates channel to also announce every new version in the channel itself, so everyone following the incident sees it.

# inc-checkout-0923
Priya Nair09:02
Payment accepted for order 4471.
Lee Park09:03
Worker request failed — no cause in the logs yet.
Priya Nair09:10
Manual retry completed.
Dana Okafor11:30
@Arialine map the confirmed checkout incident: payment succeeded, fulfillment request failed, a manual retry completed. Label the cause of the worker failure as unknown.
2Observed flow

Payment succeeded; fulfillment failed

Preserve this incident explanation before changing the design.

09:0309:10Payment acceptedFulfillment failedcause unknownManual retry completed
3Proposed follow-up

A retry queue is a proposed design change

The proposed failure path returns work to the retry queue.

Request a separate addressed change, review it and identify its owner.

on failurePayment acceptedRetry queueproposed changeFulfillment worker
4Keep both versions

The observed flow and the fix live in one history

Nothing is overwritten: the version that explains the incident stays retrievable after the follow-up change is applied.

Arialine History showing both retained checkout diagram versions
History: the original checkout flow and its accepted retry-queue revision.
5Publish the learning

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.

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.

Try one real team workflow

Install in an approved workspace, invite Arialine to the channel, create a small board and review one addressed revision.