Strategy & Planning

How to run a retrospective or post-mortem as Small IT and ITOps Teams

Strategy & PlanningFor Small IT and ITOps Teams3 apps10 steps~20 min to set up

Your last incident post-mortem lives in a Confluence page nobody will ever read again. Before that, action items from the previous retro got copy-pasted into a Jira ticket that was closed without resolution. As a 2-person IT team supporting 300 users, you're lucky if you carve out 45 minutes to debrief an outage — and when you do, half that time is spent reconstructing what actually happened by scrolling Slack threads and Jira comments. There's no template, no owner, no follow-through mechanism. The same AWS cost spike or Okta provisioning gap shows up two quarters later because the fix never got tracked to completion.

Build this on Starch → See the apps used

Strategy & PlanningFor Small IT and ITOps Teams3 apps10 steps~20 min to set up

Outcome

What you'll set up

A structured post-mortem surface that pulls timeline data from Jira, PagerDuty, and AWS into one place so you're not reconstructing incidents from memory

A living action-item tracker linked to your retro notes so every 'we should fix this' actually gets assigned, dated, and followed up

A searchable retro archive in Knowledge Management so when the same incident pattern recurs, you can find what you tried last time in seconds

The Starch recipe

Apps, data, and prompts

The combination of Starch apps, the data sources they pull from, and the prompts you use to drive them.

Apps used

Knowledge Management Project Management Meeting Notes

Data sources & config

Connect Jira and PagerDuty from Starch's integration catalog — the agent queries them live when your post-mortem app runs to pull in linked tickets and alert history. Starch connects directly to AWS so cost anomaly data from relevant incidents is available on demand. Notion is connected from Starch's integration catalog so existing runbooks can be referenced during retro synthesis. Meeting Notes handles call transcription natively; outputs feed directly into Knowledge Management.

Prompts to copy

Build me a post-mortem template app that captures incident timeline, root cause, contributing factors, and action items. Pull in linked Jira tickets and PagerDuty alerts for context. After each retro, store the summary in my knowledge base tagged by incident type and system affected.

Create a project to track every action item from today's post-mortem. Assign each item to either me or Alex, set priority levels, and flag anything not closed within 14 days.

Transcribe this retro call, extract the timeline of events, decisions made, and action items assigned, then save the summary to my Knowledge Management base under 'Incident Retrospectives / April 2026'.

Run these in Starch → or paste them into your favorite agent

Walkthrough

Step-by-step

1 Connect Jira, PagerDuty, and Notion from Starch's integration catalog so the agent can pull incident tickets, alert timelines, and existing runbooks when you kick off a retro.

2 Tell Starch: 'Build me a post-mortem template that captures incident start time, detection time, resolution time, root cause, contributing factors, and action items — pre-populated from the linked Jira incident ticket and PagerDuty alert.' Starch assembles the surface; you fill in the gaps instead of starting from a blank doc.

3 Run your retro call with Meeting Notes active. It transcribes in real time and generates a summary with key decisions and action items when the call ends — no one has to be the designated note-taker.

4 Review the auto-extracted action items. Tell Starch: 'Create tasks in Project Management for each action item from today's retro. Assign the Okta provisioning gap to me and the PagerDuty alert tuning to Alex, both due in 7 days, P2 priority.'

5 Starch creates the tasks with assignees and due dates. No clicking through Jira forms. No copy-pasting from a doc into a ticket.

6 Tell Starch: 'Save this post-mortem to Knowledge Management under Incident Retrospectives, tagged with: AWS, cost anomaly, April 2026.' The retro is now searchable alongside every future and past post-mortem.

7 Set up a recurring check: 'Every Friday at 10am, show me all open action items from post-mortems that are past due or due within 3 days.' This runs as an automation against your Project Management data — no manual triage.

8 Before your next incident debrief, tell Starch: 'Search Knowledge Management for any past post-mortems involving AWS cost spikes or billing anomalies.' The agent surfaces relevant history so you're not solving the same problem twice.

9 At the end of each quarter, tell Starch: 'Give me a summary of all post-mortems from the past 90 days — how many incidents, most common root cause categories, and which action items were never closed.' This runs against your Knowledge Management archive.

10 Use that summary as your quarterly IT review input for leadership or finance — pulled from real data, not assembled manually from scattered docs.

See this running on Starch

Connect your tools, describe what you want, and the agent builds it. Closed beta is free.

Try it on Starch →

Worked example

March 2026 AWS Billing Spike — ITOps Post-Mortem

Sample numbers from a real run

Incident detection lag (Slack alert to ticket open)	4
Hours reconstructing timeline from Slack + Jira before retro	2
Action items generated in retro	6
Action items still open 30 days later (before Starch)	4
Action items still open 30 days later (after Starch)	1

On March 14th, AWS spend spiked $3,200 above baseline — a misconfigured Lambda running in a loop that hit the cost anomaly threshold at 2am. By the time the team saw it at 9am, $400 in unnecessary compute had already accrued. The retro was scheduled for March 16th. Before Starch, 2 of the 45-minute session was spent reconstructing a timeline from Slack DMs and Jira comments because no one had written down the sequence of events. The post-mortem doc lived in a Confluence page. Six action items were captured: fix the Lambda timeout, tag all resources with cost-center, tune the CloudWatch alert threshold, update the runbook, add a budget alert for the dev account, and schedule a quarterly AWS cost review. Thirty days later, four of six were still open — the runbook update and quarterly review had no owner and no due date. After setting up the Starch retro workflow: the March post-mortem was pre-populated from the linked Jira ticket and AWS data before the call started. Meeting Notes transcribed the session and extracted all six action items automatically. Starch created project tasks for each, assigned them to the right person, and set 7-day due dates. The follow-up automation flagged two items as overdue on day 8. One month out, five of six were closed. The post-mortem itself is now searchable in Knowledge Management — when a similar Lambda issue surfaced in May, the team found the March retro in under 30 seconds and skipped rebuilding the timeline entirely.

Measurement

How you'll know it's working

Mean time to post-mortem completion (from incident close to retro doc published)

Percentage of retro action items closed within 14 days

Repeat incident rate — same system or root cause appearing in two consecutive quarters

Time spent reconstructing incident timeline before retro (target: under 10 minutes)

Number of post-mortems with a searchable archived record vs. lost in a doc nobody bookmarked

Comparison

What this replaces

The other ways teams handle this today, and how the Starch version compares.

Confluence + Jira (manual)

Free if you already pay for Atlassian, but every post-mortem is a blank page — no auto-population from incident data, no action-item tracking that follows through, and search only works if you remembered to tag things correctly.

Notion post-mortem template

Good starting structure but fully manual — you're still reconstructing timelines by hand and copy-pasting action items into a separate tracker that nobody checks.

Blameless or Rootly

Purpose-built incident retrospective platforms with strong timeline tooling, but priced for engineering orgs with dedicated SRE teams — overkill and over-budget for a 2-person IT team that runs maybe one formal post-mortem a month.

Google Docs + a shared spreadsheet for action items

Zero cost and zero friction to start, but the spreadsheet becomes stale within two weeks and there's no connection to the tickets or alerts that generated the incident in the first place.

On Starch RECOMMENDED

One platform — knowledge management, project management, meeting notes all running on connected data. Setup in plain English; numbers stay current via scheduled syncs and live agent queries.

Try it on Starch →

FAQ

Frequently asked questions

We already use Jira for incident tickets. Does Starch replace that?

No. Starch connects to Jira from its integration catalog and queries your existing tickets live when your post-mortem app runs. You keep managing incidents in Jira. Starch pulls that data into your retro surface so you're not reconstructing what happened manually — and then tracks the action items that come out of the retro, which Jira alone doesn't do well.

What if our retros are async — no live call, just a doc?

Meeting Notes is most useful for synchronous calls, but the retro template and action-item tracking work for async too. Tell Starch: 'Build me a post-mortem form my team fills out async — timeline, root cause, what we'd do differently, and action items — then create project tasks from the action items when the form is submitted.' You get the same follow-through without needing everyone on a call.

Can Starch pull PagerDuty alert history automatically into a retro?

Yes. Connect PagerDuty from Starch's integration catalog and the agent can query incident and alert data live when your post-mortem app runs. You'd tell Starch something like: 'Pre-populate the incident timeline section from the PagerDuty alert ID linked in this Jira ticket.' It won't have stored historical snapshots — data is queried live — but for the incident you're actively debriefing, the data is there.

Is Starch SOC 2 certified? Our IT security policy requires it for tools that touch incident data.

Starch is not SOC 2 Type II certified today. If your security policy requires it for a tool that touches PagerDuty alerts or AWS cost data, that's a real constraint and worth flagging before you build. It's on the roadmap.

What happens to our retro history if we already have 2 years of post-mortems in Confluence?

Starch connects to Notion from its integration catalog for knowledge management workflows. For Confluence, you'd use Starch's browser automation to pull or migrate content — Starch automates Confluence through your browser, no API required. Or you treat the archive as a fresh start and build the searchable history forward from today. Either way, new retros are archived and searchable in Knowledge Management going forward.

We only do a formal post-mortem maybe once a month. Is this overkill?

The retro workflow is probably 30 minutes to set up. The ongoing value is the archive — after 6 months, you have a searchable record of every incident pattern, root cause, and unresolved action item. That's what stops you from solving the same AWS misconfiguration or Okta provisioning gap twice. Low-frequency use case, high-value compounding output.