Markdown Incident Review to Confluence
Convert a Markdown incident review into a Confluence page with timeline, impact, root cause, and follow-up actions.
Direct answer
To publish an incident review in Confluence, structure the Markdown around summary, impact, timeline, root cause, what went well, what went wrong, and follow-up actions, then convert tables, action lists, code identifiers, and warning notes into Confluence wiki markup.
Open Markdown to Confluence converterWhen to use this
- An incident retro starts as Markdown notes.
- The final review needs to live in Confluence for support and engineering.
- The review includes a timeline table, owners, action items, or alert names.
Steps
- Write a short summary and user impact first.
- Put events in a timeline table with time, event, and owner.
- Separate root cause from contributing factors.
- List follow-up actions with owners and due dates.
- Convert the Markdown to Confluence wiki markup and link the final page from the incident ticket.
Example conversion
## Incident review ### Summary API errors increased after the 10:05 deploy. ### Timeline | Time | Event | Owner | | --- | --- | --- | | 10:05 | Deploy completed | Engineering | | 10:12 | `api_error_rate` alert fired | On-call | | 10:20 | Rollback completed | On-call | ### Root cause A required environment variable was missing from production. ### Follow-up actions - Add deploy-time config validation - Add runbook step for environment checks
h2. Incident review
h3. Summary
API errors increased after the 10:05 deploy.
h3. Timeline
|| Time || Event || Owner ||
| 10:05 | Deploy completed | Engineering |
| 10:12 | {{api_error_rate}} alert fired | On-call |
| 10:20 | Rollback completed | On-call |
h3. Root cause
A required environment variable was missing from production.
h3. Follow-up actions
* Add deploy-time config validation
* Add runbook step for environment checksCommon mistakes
- Do not mix timeline facts with root-cause interpretation.
- Do not leave follow-up actions without owners.
- Do not paste alert names as plain prose if inline code would make them easier to identify.
FAQ
- What sections should a Confluence incident review include?
- Use summary, impact, timeline, root cause, contributing factors, what went well, what went wrong, follow-up actions, owners, and links to alerts or tickets.
- Should the incident timeline be a table?
- Usually yes. A timeline table is easier to scan than a paragraph and converts cleanly into Confluence wiki table markup.
- How should follow-up actions be formatted?
- Use bullets or a table with action, owner, due date, and status. Confluence can then track the work more clearly.
Related Confluence guides
Markdown Runbook to Confluence
Convert a Markdown runbook into Confluence wiki markup with steps, warnings, code blocks, and rollback notes.
Confluence Technical Spec Template
Format a Markdown technical spec for Confluence with problem, decision, architecture, tradeoffs, and open questions.
Markdown Meeting Notes to Confluence
Turn Markdown meeting notes into a Confluence page with decisions, action items, blockers, and links.
Paste Markdown into Confluence (Without Broken Formatting)
Convert the Markdown to Confluence wiki markup, then paste it through Insert > Markup. That is the only way headings, tables, and code blocks survive. Raw Markdown pastes as plain text.
Markdown Table to Confluence
Convert Markdown pipe tables into Confluence wiki markup tables with proper header rows, and avoid the collapses that happen when you paste tables directly.
Markdown Code Blocks to Confluence
Turn Markdown fenced code blocks into Confluence {code} macros with syntax highlighting, and know when to use {noformat} instead.
Markdown Checklists to Confluence
Convert Markdown task lists (- [ ] and - [x]) into Confluence-friendly checklists using (/) and (x) status icons, or the editor's action items.