Post-Mortems

Alga provides a structured, blameless post-mortem workflow for incidents, with review/approval processes and trackable action items. Each post-mortem is linked 1:1 to an incident (incident_id is unique).

Post-Mortem Lifecycle

draft → in_review → approved → published

Status	Description
draft	Initial creation, being written
in_review	Submitted for review
approved	Reviewed and approved (records approved_by_id)
published	Publicly visible (records published_at)

Allowed transitions: draft → in_review; in_review → draft or approved; approved → in_review or published. published is terminal — published post-mortems cannot be edited or reverted (PATCH returns 409). Submitting for review requires blameless_confirmed to be set and notifies the incident commander that a review is requested.

Content Fields

A post-mortem includes the following fields:

Field	Description
title	Post-mortem title
summary	Brief description of what happened
timeline	Key events during the incident (structured JSON)
root_cause	Technical explanation
contributing_factors	Additional factors that contributed (list)
impact	Duration, affected services, user impact
what_went_well	Things that worked during the response
what_went_wrong	Things that did not work or could be improved
lessons_learned	What was learned and what could be improved
blameless_confirmed	Acknowledgement that the review is blameless
blameless_notes	Notes supporting the blameless confirmation

AI Draft Builder

When an incident is resolved, Alga can auto-create a post-mortem draft pre-populated from incident context — the incident document sections, coordination messages, timeline entries, status updates, and linked alerts. The same enrichment logic backs both the operator resolve flow and the agent resolve tool.

Action Items

Action items are tracked per post-mortem and can be assigned, prioritized, and driven to completion.

Field	Description
description	What needs to be done (required)
type	Kind of follow-up (prevent, mitigate, detect, investigate; defaults to investigate)
assignee_id / assignee_name	User responsible (assignee_id must reference an existing user; reassignment notifies the new assignee)
status	open → in_progress → completed (or cancelled; defaults to open)
priority	Priority level (low, medium, high; defaults to medium)
due_date	Target completion date — RFC3339 timestamp or YYYY-MM-DD (interpreted as end of day UTC)

Action item mutations are scoped to the path incident: an item id from a different incident's post-mortem returns 404. Overdue items (due date in the past, not completed/cancelled) are detected by a background sweep every 5 minutes; the sweep emits an action_item_overdue SSE event and notifies the assignee at most once per item per 24 hours.

View all open action items globally at GET /api/v1/action-items (sorted by due date, undated items last).

Workflow

1. Create the post-mortem (auto-drafted on resolve, or created manually)
2. Edit content as needed (while in draft; editing is allowed in any non-published state)
3. Submit for Review — moves to in_review and notifies the commander (requires blameless_confirmed)
4. Approve — moves to approved and records the approver
5. Publish — moves to published (immutable)
6. Track Action Items — ensure follow-up tasks are completed
7. Revert — in_review/approved post-mortems can be returned to draft (or approved to in_review) via POST …/revert-to-draft / POST …/revert-to-review

API Endpoints

Post-Mortem Management

Method	Path	Auth	Permission	Description
GET	/api/v1/post-mortems	Session	postmortems:read	List all post-mortems
GET	/api/v1/incidents/{id}/post-mortem	Session	postmortems:read	Get post-mortem
POST	/api/v1/incidents/{id}/post-mortem	Session	postmortems:write	Create post-mortem
PATCH	/api/v1/incidents/{id}/post-mortem	Session	postmortems:write	Update post-mortem (409 when published)
DELETE	/api/v1/incidents/{id}/post-mortem	Session	postmortems:delete	Delete post-mortem

{id} accepts either the incident number or the incident UUID.

Workflow Actions

Method	Path	Auth	Permission	Description
POST	/api/v1/incidents/{id}/post-mortem/submit-review	Session	postmortems:write	Submit for review (in_review)
POST	/api/v1/incidents/{id}/post-mortem/revert-to-draft	Session	postmortems:write	Return in_review/approved to draft
POST	/api/v1/incidents/{id}/post-mortem/revert-to-review	Session	postmortems:write	Return approved to in_review
POST	/api/v1/incidents/{id}/post-mortem/approve	Session	postmortems:write	Approve post-mortem
POST	/api/v1/incidents/{id}/post-mortem/publish	Session	postmortems:write	Publish post-mortem

Action Items

Method	Path	Auth	Permission	Description
GET	/api/v1/incidents/{id}/post-mortem/action-items	Session	postmortems:read	List action items
POST	/api/v1/incidents/{id}/post-mortem/action-items	Session	postmortems:write	Create action item
PATCH	/api/v1/incidents/{id}/post-mortem/action-items/{itemId}	Session	postmortems:write	Update action item
DELETE	/api/v1/incidents/{id}/post-mortem/action-items/{itemId}	Session	postmortems:delete	Delete action item

Global Action Items

Method	Path	Auth	Permission	Description
GET	/api/v1/action-items	Session	postmortems:read	All open action items

See Also

• Incident Lifecycle — state transitions and resolution requirements
• Incident Overview — creation and management