How do I put dashboards in a postmortem without screenshots?

Export the panel or snapshot as HTML and publish it with the writeup. The reader gets working tooltips and axes instead of a cropped PNG whose y-axis was cut off, and the evidence stays readable after the dashboard's retention window closes.

Why not keep the postmortem in the wiki?

Keep it there if the wiki renders your artifacts. Most don't — flamegraphs, trace viewers and dashboard exports get flattened or rejected on upload. Publishing the artifact and linking it from the wiki page keeps both surfaces doing what they're good at.

Can responders annotate the timeline directly?

Yes. Comments anchor to the line they're about, so 'we were already rolling back by here' lands on that timestamp rather than in a review meeting nobody minuted.

Does the link survive the retro?

Yes — the report has its own retention, independent of dashboard snapshot expiry or CI artifact cleanup. A link in an old incident ticket still opens a year later.

Can the incident report be generated automatically?

Yes. Publish from the job, the runbook script, or an agent over REST or MCP, and revise the same report as the incident develops rather than sending a new link each update.

Postmortems that keep their evidence

An incident review is an argument about a sequence of events, and the evidence for it is almost entirely visual: a latency graph, a saturation chart, a flamegraph, a trace. The standard workflow destroys all of it. Someone screenshots Grafana at 2am, crops the y-axis off, pastes it into a doc, and six weeks later nobody can tell whether that spike was 200ms or 2s.

Then the dashboard's snapshot expires, and the only remaining record is the cropped PNG.

Publish the artifacts, link them from the writeup

The postmortem document can live wherever your team already writes — wiki, repo, ticket. What it needs is working links to things that render:

Grafana dashboards · Kibana · Datadog
Flamegraphs · Speedscope · py-spy · async-profiler
Load-test evidence: k6 · JMeter · Gatling · Locust · Vegeta
pgBadger for the database side of a bad night.

Scripts run inside a sandboxed iframe, so a flamegraph still zooms and a dashboard export still shows its tooltips. That is the whole point: the thing being argued about stays inspectable.

Or publish the whole thing as one report

For a full incident review, the writeup is HTML — generated from a template, or by an agent from the incident channel — with the graphs inline. One report, one URL, one place the conversation happens.

Then run the review on the document itself. Anchored comments mean "we'd already started the rollback by here" attaches to that timestamp in the timeline, and "this is the wrong root cause" attaches to the claim it disputes. See commenting on HTML.

Blameless review works better when the disagreement is visibly about a line rather than about a person in a meeting.

During the incident, not just after

An incident report is not a one-shot document. Publish it early and revise the same report as facts change:

curl -fsS -X PATCH "https://commareports.com/api/v1/reports/$INCIDENT_REPORT_ID" \
  -H "Authorization: Bearer $COMMA_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d @incident.json

One link goes in the status channel at minute five and stays correct at hour three. Nobody asks which of the four documents is current, because there is one address.

Standing digests

Error-budget burn, weekly reliability summaries, monthly capacity reviews: these are routines — a schedule, a regeneration, a revision at the same URL. See scheduled HTML reports and weekly analytics digest.

Worth knowing

Retention is yours. Dashboard snapshots and CI artifacts expire on someone else's schedule; a published report doesn't. See CI artifact expired.
Private first. Incident writeups name customers, internal hostnames and sometimes people. Publish private, widen to the team, and decide separately whether a redacted version goes public — see sharing & access control.
Readers are free. Support, sales engineering and execs who only read are never charged.
Limits. Entry HTML 5 MB; assets 25 MB per file, 250 MB and 500 files per report. Trace exports are the usual file-count offender.

Try it

Comma is free — unlimited reports, unlimited commenters, unlimited revision history.

Start free →