DEV Community: Yamuno

Jira Reporting for Product Managers: Charts, Metrics, and Dashboards

Yamuno — Tue, 14 Jul 2026 10:00:30 +0000

Jira Reporting for Product Managers: Charts, Metrics, and Dashboards

Product managers and engineering teams look at the same Jira data and need completely different things from it. Engineering wants sprint health, cycle time, and blocked issue counts. Product management wants feature progress, release readiness, customer-reported bug trends, and backlog composition.

Most Jira dashboards are set up by or for engineering teams. If you're a PM who has tried to get useful reporting out of Jira and ended up with a page full of gadgets that don't answer your actual questions, this guide is for you.

The Four Questions a PM Dashboard Should Answer

Before picking any chart, start with the questions:

What's the state of the current release? — Feature completion, open bugs, scope changes
What's the trend for customer-reported issues? — Bug volume over time, resolution rate
What does the backlog look like? — Priority distribution, backlog by product area
What shipped recently? — Completed features, closed bugs, release notes fodder

If your dashboard can answer these four questions without anyone opening a filter or running a query, it's doing its job.

Chart 1 — Release Progress Bar

The question: How far along are we in the current release?

Setup:

Chart type: Bar (stacked)
Filter: fixVersion = "Your Release Name"
Group by: Status
Show: To Do, In Progress, In Review, Done as stacked segments

A stacked bar with one bar showing all four statuses tells you at a glance: how much is done, how much is in flight, and how much hasn't started. When the Done segment is 80%+ of the bar with a week left in the release, you're in good shape. When To Do still represents 40% with the release date looming, you have a scope problem.

JQL filter:

project = YOURPROJECT AND fixVersion = "v2.4" AND issueType in (Story, Bug, Task)

Chart 2 — Customer-Reported Bug Trend

The question: Is the volume of customer-reported bugs stable, increasing, or decreasing?

Setup:

Chart type: Line
Filter: label = "customer-reported" (or however your team tags customer bugs)
X-axis: Week or month
Y-axis: Issue count created in that period

This chart is most useful over a 90-day window. A stable horizontal line means your product quality is consistent. An upward trend after a release means the release introduced regressions. A downward trend is good news — though confirm it's not just a drop in reporting.

If your team doesn't use a consistent label for customer-reported issues, this is the right time to establish one. The reporting value is significant.

Chart 3 — Feature vs. Bug Ratio in the Backlog

The question: Is the backlog dominated by one type of work?

Setup:

Chart type: Pie or donut
Filter: Open issues in the project
Group by: Issue type

For a product team, the ideal ratio depends on the product maturity stage. A new product might be 80% features and 20% bugs. A mature product with a large install base might be 50/50. What you're watching for is a trend — if the bug proportion grows every quarter, quality investment is falling behind.

This is also useful for product strategy conversations: when engineering says they need a "bug bash sprint," this chart gives you the data to support (or challenge) the request.

Chart 4 — Backlog by Priority

The question: How much of the backlog is urgent?

Setup:

Chart type: Bar (horizontal)
Filter: Open issues in backlog
Group by: Priority

A priority bar chart shows how the backlog breaks down by Critical, High, Medium, and Low. The ratio matters: a backlog that's 30% Critical and 40% High is telling you that your priority labels have inflated to the point of meaninglessness, or that there's genuinely too much urgent work and the team can't keep up.

Review this chart before each quarterly planning cycle. If the High bar keeps growing despite the team working on High-priority issues, capacity is mismatched with demand.

Chart 5 — Completed Work by Area

The question: What shipped this quarter, and in which product areas?

Setup:

Chart type: Bar
Filter: status = Done AND updated >= -90d
Group by: Label (product area labels) or Component

This chart is a retrospective view of where the team's output went. If you have labels for product areas ("auth," "billing," "reporting," "mobile"), a bar chart of completed issues by label shows what got attention. It's a useful starting point for "was this the quarter we said we'd focus on X?" conversations.

Also useful for release notes compilation — filter to the release's fixVersion and group by issue type to see what categories of work shipped in that release.

Setting Up the PM Dashboard

Create a dedicated Jira dashboard for product management. Don't share the sprint team's dashboard — the audiences and refresh cadences are different.

Recommended layout — three columns:

Left column	Center column	Right column
Release progress (bar)	Customer bug trend (line)	Backlog by priority (bar)
Feature vs. bug ratio (pie)	Completed by area (bar)	(empty or a filter results table)

Add a date range selector at the top if Charts for Jira supports a shared filter — change the range and both time-based charts update together.

Share it: Add the Confluence team, the engineering manager, and any design leads as viewers. A shared dashboard replaces the "can you pull the Jira report for the leadership update?" request with a link they can check themselves.

What Good Jira Reporting Looks Like

The sign that your dashboard is working: you open it in a meeting, look at it for 30 seconds, and can answer questions from it without typing a single JQL query. If you're still exporting to spreadsheet to get the answer you need, the dashboard isn't answering the right questions yet.

Start with the release progress chart and the bug trend. Those two alone are more valuable than most Jira dashboards that have eight gadgets.

Install Charts for Jira Dashboard →

How to Add a Cover Page to Confluence PDF Exports

Yamuno — Wed, 08 Jul 2026 10:21:04 +0000

How to Add a Cover Page to Confluence PDF Exports

Confluence's built-in PDF export produces the page content and nothing else. No title page, no table of contents, no company logo — just the raw content starting at the top of page one. For internal drafts that's workable. For anything going to a client, a stakeholder, or an external auditor, a document that starts abruptly with content and no cover page looks unfinished.

PDF Exporter for Confluence adds a cover page option with six built-in styles, full branding control, and a live preview so you can see exactly how the cover looks before exporting.

This guide covers how to set it up.

Prerequisites

Install PDF Exporter for Confluence from the Atlassian Marketplace. Cover page configuration is done through the template system, which requires Confluence admin access.

Step 1 — Open the Template Editor

Go to Confluence Settings (gear icon, top-right)
In the left sidebar, click PDF Exporter
Click Templates
Either create a New Template or click the edit (pencil) icon on an existing one

Step 2 — Enable the Cover Page

In the template editor, find the Cover Page section and toggle it to enabled.

Once enabled, the cover page configuration expands to show:

Cover style selector
Accent color picker
Subtitle field
Author field
Logo upload

A live preview on the right side of the editor updates as you make changes.

Step 3 — Choose a Cover Style

Six built-in styles are available:

Style	Best for
Classic	General-purpose documents, internal wikis
Corporate	Client-facing deliverables, formal proposals
Modern	Product documentation, technical guides
Executive	Board reports, executive summaries
Bold	Internal team reports, product launches
Minimal	When you only need the title with no decoration

Click through the styles in the selector — the preview updates immediately so you can compare them without saving.

Recommendation for client-facing documents: Corporate or Executive. Both have a restrained, professional look that works across industries. Avoid Bold for external documents — it's visually strong but can feel informal in a business context.

Step 4 — Set the Accent Color

The accent color controls the decorative elements on the cover: the color bar in Corporate style, the accent line in Executive style, the overlay block in Modern style, and so on.

Click the color field and enter your hex value. Use your company's primary brand color.

If you don't have a specific brand color, #1e40af (dark blue) or #1d4ed8 (medium blue) works well for most professional contexts. Avoid very light colors — they disappear against a white background on some cover styles.

Step 5 — Add Your Logo

Click Upload Logo and select your company logo (PNG, JPG, or SVG). The logo appears on the cover page alongside the document title.

Logo tips:

Use a horizontal logo variant if available — it fits better in most cover layouts
PNG with a transparent background looks cleanest against the cover page background
SVG scales perfectly at any size

The logo is stored per template, so you upload it once and it appears on every export using this template.

Step 6 — Configure Subtitle and Author

Subtitle: Optional text displayed below the document title. Use this for:

Version numbers ("Version 2.3 — April 2026")
Confidentiality notice ("Confidential — Not for External Distribution")
Document type ("Technical Specification")

Author: Optional name displayed on the cover. For team-produced documents, use a team or department name ("Solutions Engineering," "Product Team") rather than an individual's name — it ages better and is more appropriate for documents that will be revised over time.

Step 7 — Save and Test

Click Save. The template is now available to all users on the instance.

To test it:

Open any Confluence page
Click ••• → Export to PDF
Select your template from the dropdown
Click Preview (don't export yet — preview first)
Check the cover page in the preview modal

The preview shows the actual cover with your logo, accent color, and the Confluence page title as the document title. If anything looks off — logo too large, color doesn't match, subtitle missing — go back to the template and adjust.

How the Cover Page Interacts with the Rest of the PDF

The cover page is always the first page. It does not count in page numbering — if you have page numbers enabled, they start from "1" on the first content page after the cover.

If you also have a table of contents enabled, it appears after the cover page and before the content — the standard structure for a professional document.

[Cover Page]
[Table of Contents]  ← if enabled
[Content Pages]      ← page numbers start here

Exporting Without a Cover Page (When Needed)

Sometimes you want a clean export without a cover — a raw content dump for internal review, or a quick single-page export that doesn't need a title page.

The easiest approach is to keep a second "No Cover" template (or use the built-in Default template) for these cases. Users select the right template at export time based on what the document needs.

Install PDF Exporter for Confluence →

Read the documentation →

How to Migrate from Notion to Confluence (Step-by-Step Guide)

Yamuno — Fri, 03 Jul 2026 10:38:34 +0000

How to Migrate from Notion to Confluence

Teams migrate from Notion to Confluence for different reasons — Atlassian ecosystem consolidation, enterprise SSO requirements, tighter Jira integration, or simply an organizational decision after a company merger. Whatever the reason, the migration path is more practical than it looks.

Notion exports your content as markdown (or HTML). Confluence can import markdown. The gap between those two facts is what this guide covers: what the export gives you, what needs cleanup, and how to get everything into Confluence cleanly.

Step 1 — Export Your Notion Workspace to Markdown

In Notion:

Open Settings & Members → Settings
Click Export all workspace content
Choose Markdown & CSV as the export format
Enable Include subpages and Create folders for subpages
Click Export and download the ZIP

The export produces a ZIP with:

One .md file per Notion page
Subpages nested in folders matching the page hierarchy
Images saved as local files (usually in a folder alongside each page)
Database tables exported as .csv files

Step 2 — Understand What Transfers Well and What Doesn't

Transfers cleanly:

Text content, headings, paragraphs
Bold, italic, inline code
Bulleted and numbered lists
Code blocks with language tags
Images (as embedded files)
Basic tables

Needs manual attention:

Notion databases — exported as CSV, not as Confluence pages. Plan to recreate these as Confluence tables or use a Jira integration for structured data
Toggle blocks — exported as regular text; the expand/collapse behavior is lost
Notion-specific embeds (YouTube, Figma, etc.) — exported as plain URLs, not embedded. You'll need to re-embed them in Confluence
Linked databases and relations — not preserved in markdown export
Comments and mentions — not included in the export

For a large workspace, do a test export and import of a small section first to understand what the output looks like for your specific content before committing to a full migration.

Step 3 — Clean Up the Exported Markdown

Before importing, a few cleanup steps save time:

Remove Notion IDs from filenames. Notion appends a unique ID to every file and folder name (e.g., Engineering Wiki a3f2c1b4d5e6.md). You can strip these with a script or a bulk rename tool. The Markdown Importer uses the filename as the Confluence page title, so cleaner names give you cleaner page titles.

# macOS/Linux — remove Notion IDs from .md filenames
for f in *.md; do
  newname=$(echo "$f" | sed 's/ [a-f0-9]\{32\}\.md$/.md/')
  [ "$f" != "$newname" ] && mv "$f" "$newname"
done

Convert CSV databases to markdown tables. For Notion databases that you want in Confluence as pages (not Jira issues), convert the CSV to a markdown table:

# Quick CSV to markdown table conversion (Python)
python3 -c "
rows = list(csv.reader(open(sys.argv[1])))
print('| ' + ' | '.join(rows[0]) + ' |')
print('| ' + ' | '.join(['---'] * len(rows[0])) + ' |')
for row in rows[1:]:
    print('| ' + ' | '.join(row) + ' |')
" your-database.csv

Organize the folder structure. Notion's export mirrors its page hierarchy as nested folders. Review the structure and reorganize if needed — the folder structure becomes the Confluence page hierarchy.

Step 4 — Import into Confluence

Install Markdown Importer for Confluence from the Atlassian Marketplace.

For a small migration (up to 20–30 pages):

Open the target Confluence page (where the imported pages should live)
Click ••• → Markdown Importer & Exporter
Select your cleaned-up markdown files or the ZIP archive
Enable Page Hierarchy to preserve folder structure as Confluence parent/child pages
Click Import

For a large migration:

Use the ZIP upload option. Zip your cleaned-up Notion export folder (after stripping IDs and reorganizing) and upload it as a single archive. The importer processes the entire folder tree and creates the Confluence page hierarchy in one operation.

If you're migrating multiple Notion workspaces or sections to different Confluence spaces, you can target different parent pages and spaces in separate import operations.

Step 5 — Handle Images

Notion's markdown export embeds images as relative file paths:

![Screenshot](./Screenshot_2025-03-14.png)

Markdown Importer reads the ZIP archive and uploads images as Confluence attachments, replacing the relative paths with Confluence attachment references automatically. This works when you import via ZIP — the images need to be inside the ZIP alongside the markdown files.

If you're importing individual .md files without a ZIP, images won't transfer automatically — you'll need to upload them to Confluence and update the image references manually.

Step 6 — Post-Import Cleanup

After the import, walk through the imported pages:

Check page titles. The importer uses filenames as titles. If you missed some Notion IDs in the cleanup step, some pages will have IDs in their titles — rename them in Confluence.

Re-embed external content. Notion embeds for YouTube, Figma, Loom, or other services come through as plain URLs. Add Confluence macros or HTML Macro embeds to restore the embedded experience where it matters.

Review tables. Notion tables with select, multi-select, or date columns export as text — the structured data type is lost. Verify these look reasonable in Confluence or recreate them using Confluence's table macro.

Update internal links. Links between Notion pages are relative paths in the export and may not resolve correctly after import. Run a search in Confluence for notion.so URLs to find any that were hardcoded, and update them to Confluence page links.

What to Expect at Scale

For a workspace with 200–500 pages, the full migration — export, cleanup, import — typically takes a day of dedicated effort. Larger workspaces benefit from dividing the work by Notion workspace section and importing incrementally rather than all at once.

The most time-consuming part is usually the post-import cleanup: reviewing imported pages, fixing database content, and re-embedding media. Budget more time for this than for the import itself.

Install Markdown Importer for Confluence →

Read the documentation →

How to Track Jira Issues with Charts and Graphs

Yamuno — Tue, 30 Jun 2026 11:11:57 +0000

How to Track Jira Issues with Charts and Graphs

Jira stores detailed data about every issue — status, assignee, priority, type, labels, sprint, creation date, resolution date. The challenge isn't getting the data into Jira. It's getting anything useful out of it without building a spreadsheet report from scratch every week.

This guide covers the most practical chart setups for tracking Jira issues — what to visualize, how to configure it, and what to look for in the output.

Getting Started

Charts - Reports and Graphs for Jira Dashboard adds chart gadgets to Jira dashboards. Install it from the Atlassian Marketplace, then add a gadget to any Jira dashboard by clicking Add gadget → Charts for Jira Dashboard.

Each gadget is configured independently — choose the chart type, data source (project, JQL query, or label filter), grouping, and visual options.

1. Status Distribution — Where Is Everything Right Now?

The most immediate question for any sprint or project is: how many issues are in each status?

Chart type: Bar (horizontal)
Group by: Status
Filter: Current sprint or open issues in the project

A horizontal bar chart with one bar per status — To Do, In Progress, In Review, Done — gives you the snapshot at a glance. When "In Review" is twice as wide as "In Progress," you know reviews are backing up.

For a kanban team without sprints, filter to "all open issues" and group by status. The relative bar lengths show your work in progress distribution and immediately reveal if one column is accumulating more than expected.

2. Assignee Workload — Is Work Distributed Evenly?

Chart type: Bar (vertical or horizontal)
Group by: Assignee
Filter: Open issues in current sprint or project

This chart answers the question that comes up in every sprint planning meeting: is the work actually balanced? One bar per team member, height representing open issue count.

The useful insight isn't just the current distribution — it's the pattern over multiple sprints. If the same one or two people consistently have the highest bars, that's a structural problem worth addressing, not a one-sprint anomaly.

Refinement: Add a second dataset for "In Progress" issues only (by adding a JQL filter status = "In Progress"). Now you can see not just who has the most assigned, but who is actively working on the most issues simultaneously — which is a better signal for overload.

3. Priority Breakdown — Where Are the Critical Issues?

Chart type: Pie or bar
Group by: Priority
Filter: Open issues in the project

A priority pie chart shows the proportion of Critical, High, Medium, and Low issues in your backlog. This is most useful for bug tracking and escalation management.

If you're watching this chart over time (check it at the start of each sprint), a growing "Critical" slice is an early warning sign that something in your triage process or product isn't working. A shrinking "High" slice alongside increasing "Critical" might mean labels are being inflated.

Practical use: Share this chart in your sprint retrospective. If the team sees that 40% of issues tagged Critical are consistently de-prioritized, the label is losing meaning — worth a conversation.

4. Issue Type Distribution — What Kind of Work Are We Doing?

Chart type: Pie or donut
Group by: Issue type
Filter: Issues created in the last 30 days, or current sprint

Jira issue types (Bug, Feature, Task, Story, Spike, Tech Debt) tell you the composition of what the team is actually working on. If your roadmap says "feature development sprint" but the chart shows 60% bugs, you have a planning alignment issue.

This chart is most useful at the project or team level, not the sprint level — one sprint's composition can be an anomaly. The 30-day or 90-day view shows the actual pattern.

5. Sprint Progress — Are We on Track to Complete?

Chart type: Bar (grouped or stacked)
Group by: Status
Filter: Current sprint

A grouped bar chart with two bars — "Completed" and "Remaining" — is a straightforward sprint progress view. Set it up at sprint start and check it mid-sprint. The relative bar heights tell you immediately whether you're ahead, on track, or behind.

For a more nuanced view, use a stacked bar grouped by status: a single bar per sprint with segments for To Do, In Progress, In Review, and Done. This shows not just completed vs. remaining, but where the remaining work is sitting.

JQL for current sprint:

project = YOURPROJECT AND sprint in openSprints()

6. Label-Based Tracking — Custom Dimensions

Jira labels are underused for reporting. If your team uses consistent labels — "customer-request," "regression," "tech-debt," "blocked" — you can build charts that filter to those labels.

Example: A bar chart filtered to label = "customer-request" grouped by status shows how many customer-requested issues are open vs. in progress vs. done. This is the chart that goes in a customer success update without you needing to manually compile a list.

Example: A count of label = "blocked" issues over time (if you're logging blocked state via label) reveals whether your impediment rate is stable or trending up.

Building a Dashboard Around These Charts

A practical dashboard for a sprint team: three gadgets on one board.

Gadget	Chart	Data
1	Status distribution (bar)	Current sprint issues
2	Assignee workload (bar)	Open issues, current sprint
3	Priority breakdown (pie)	Open bugs in the project

That's enough to run a 15-minute sprint check-in without opening any Jira filters. Everyone looks at the same charts, asks questions from the same data, and the meeting moves faster.

Add a date filter at the top of the dashboard and make it the single control that drives all three gadgets. When stakeholders ask "what did we do last month," you change the date range and the answer is visible immediately.

Install Charts for Jira Dashboard →

Exporting Confluence Documentation for Clients: A Practical Guide

Yamuno — Wed, 24 Jun 2026 10:52:41 +0000

Exporting Confluence Documentation for Clients

Most Confluence documentation is written for internal audiences — people who have access to the instance and can navigate the space directly. But plenty of documentation ends up going to people who don't have Confluence access: clients receiving a project handover, stakeholders reviewing a technical spec, partners getting onboarded, or auditors requesting documentation exports.

Confluence's built-in PDF export exists, but it produces bare output: no cover page, no custom headers, no watermarks, and no way to save a consistent format so the next export looks like this one. For internal drafts that's fine. For a client deliverable, it's not.

This guide covers how to export professional, consistently formatted PDFs from Confluence for external distribution using PDF Exporter for Confluence.

The Setup: Admin Creates a Template, Users Apply It

The key to consistent output across a team is templates. An admin creates a "Client Deliverable" template once in Confluence Settings. After that, any team member exporting for a client selects that template and gets the same cover page, header, and formatting — without touching any configuration themselves.

Admin step (one time):

Go to Confluence Settings → PDF Exporter → Templates → New Template
Name it "Client Deliverable"
Configure it as described below
Save

User step (every export):

Open the Confluence page or parent page to export
••• → Export to PDF
Select "Client Deliverable" template
Choose scope (single page, page tree, or space)
Export and download

Recommended Template Settings for Client-Facing PDFs

Cover Page

Enable the cover page. For client deliverables, Corporate or Executive style works best:

Corporate — left-aligned with a solid color accent bar, professional and structured
Executive — minimal with a thin accent line, suits formal proposals and executive-level documents

Set the accent color to your company's primary brand color (hex). Upload your company logo. Add a subtitle field — "Prepared for [Client Name]" or "Confidential — [Date]" — as a manual step per export.

Header

Enable the header with your company name or document series title, centered. This appears on every content page and reinforces the source of the document even when pages are printed individually.

Footer

Add page numbers (right-aligned) and a confidentiality notice (left-aligned):

Confidential — [Company Name]                                       Page 1 of 10

This combination is standard for client-facing documentation in most professional services contexts.

Watermark

For documents that are drafts or under review, enable the watermark with "DRAFT" at 0.15 opacity. Remove it from the template (or create a separate "Client Draft" template) when the document is final.

Enable for any multi-page export. Set depth to 2 (H1 and H2). This is especially important for handover packages and technical specs where clients need to navigate to specific sections.

Page Breaks

Enable "Break before H1" so each major section starts on a new page. For longer documents, also enable "Break before H2."

Common Export Scenarios

Project Handover Package

A handover package typically spans multiple Confluence pages — architecture overview, runbooks, configuration guides, contact lists. Export the entire section as a page tree:

Navigate to the parent page of the handover section
••• → Export to PDF
Select the page tree — uncheck any internal-only pages you don't want in the client copy
Select "Client Deliverable" template
Export — downloads as a ZIP with each section as a separate PDF

Alternatively, if you want a single combined PDF, check all pages under one parent. The exporter bundles them in page tree order.

Technical Specification

A single-page export is appropriate for a spec document or proposal:

Open the spec page
••• → Export to PDF
Select "Client Deliverable" template
Export — single PDF download

If the spec has an H1-level structure with multiple major sections, the table of contents and page breaks make it easy to navigate without Confluence access.

Compliance Documentation Export

For regulatory submissions or audit requests, use a separate "Compliance Archive" template with:

Executive cover style
Watermark: "ARCHIVED" or "CONFIDENTIAL" at 0.2 opacity
Footer: department name and export date
No table of contents unless required by the submission format

Create this template with watermark enabled by default so it's never accidentally omitted on a compliance export.

Recurring Status Report

If you export a weekly or monthly status report page to send to a client, the template eliminates the manual formatting step entirely. Update the Confluence page with new content, export with the "Client Deliverable" template, and the output is ready to send. The cover page, header, and formatting are consistent every time without any effort.

Space Export for Full Documentation Sets

For clients receiving a complete documentation set (e.g., a full product documentation space), use the space export:

From the global Apps menu, open PDF Exporter for Confluence
The page tree for the current space is displayed
Select all pages or deselect internal-only pages
Apply the template
Export — downloads as a ZIP of PDFs matching the space hierarchy

This is useful for project completion handovers, vendor certifications, or any situation where the client needs a complete copy of a documentation space they won't have ongoing access to.

Before You Send

Before the PDF goes to the client:

Use the Preview option in the exporter to verify the cover page, header, and first few pages look correct
Check that the subtitle on the cover page reflects the correct client name or document version
Confirm the watermark is absent if the document is final (or present if it's still a draft)
Open the downloaded PDF to verify the table of contents links work and the page numbering is correct

The preview step takes 30 seconds and catches the issues — wrong accent color, missing logo, leftover watermark — that would otherwise be visible to the client.

Install PDF Exporter for Confluence →

Read the documentation →

How to Manage Confluence Attachments at Scale

Yamuno — Sat, 20 Jun 2026 10:34:44 +0000

How to Manage Confluence Attachments at Scale

Confluence storage fills up in a predictable way. Teams upload screenshots, export files, and old versions of diagrams. Pages get reorganized or deleted. The attachments stay. After a year or two, a significant portion of your Confluence storage is files that are no longer referenced by any page — orphaned attachments that cost storage budget without serving any purpose.

Cleaning this up manually is impractical at any scale. This guide covers how to audit and manage Confluence attachments systematically using Advanced Attachment Manager for Confluence.

The Core Problem: Unused Attachments

An unused attachment is a file that was uploaded to Confluence but is no longer referenced anywhere in page content. This happens when:

A page is deleted but its attachments remain
An image is uploaded, replaced by a newer version, and the old version is left
A file is attached to a page during a draft but never embedded in the final content
Content is migrated from one space to another and the source attachments are left behind

Confluence's native attachment view shows you files per page. It doesn't have a cross-space view, doesn't flag unused files, and doesn't support bulk operations. Advanced Attachment Manager does.

Step 1 — Find Unused Attachments

Open Advanced Attachment Manager from the Confluence global navigation: Apps → Advanced Attachment Manager.

The first filter to apply: Usage Status → Unused. This surfaces every attachment in the selected scope (page, space, or instance-wide) that isn't currently referenced by any page content.

For most Confluence instances that haven't been audited recently, this list is longer than expected. Sort by File Size (descending) to see the biggest storage consumers first — a handful of large video files or exported PDFs often account for a disproportionate share.

Step 2 — Filter Down to What's Safe to Delete

Not every unused attachment should be deleted. Some are referenced in archived pages. Some are version history that someone may need to reference. Apply additional filters to narrow to what's clearly safe:

Filter by file type: Images and exported PDFs are the most common orphans. Filter to Images or Documents to work through the most common cases first.

Filter by upload date: Files uploaded more than 12 months ago and never used are strong candidates for deletion. Set the upload date range to filter out recent uploads.

Filter by uploader: If a departed team member uploaded most of the unused files, filtering by uploader gives you a focused list to review.

Use shift-click and ctrl/cmd-click to select individual files, or Select All after applying filters to select the entire filtered result set.

Step 3 — Download Before Deleting (When Uncertain)

For any batch where you're not 100% confident, use Bulk Download before deleting. This downloads all selected files as a ZIP archive to your local machine.

Bulk Download is also useful for migration and archival purposes — before decommissioning a Confluence space, download all attachments to preserve them outside Confluence.

Step 4 — Bulk Delete

With the files selected:

Click Delete Selected
Review the confirmation dialog — it shows the count and total size being freed
Confirm the deletion

Deletions are logged to the audit trail immediately. If you delete something that turns out to be needed, check the audit log first to confirm what was removed, then check if it can be recovered from Confluence's trash.

Step 5 — Review the Audit Log

Every action taken in Advanced Attachment Manager — views, downloads, deletions — is recorded in the audit log. Access it from the app sidebar.

The audit log shows:

Action type (deleted, downloaded, viewed)
File name and size
Space and page the file was attached to
User who performed the action
Timestamp

This is important for compliance-sensitive environments: you have a complete record of what was removed, by whom, and when.

Scheduling Regular Cleanups

Attachment management is most effective as a recurring process rather than a one-time cleanup. A quarterly cadence works for most teams:

Filter to unused attachments uploaded more than 90 days ago
Sort by size, work through the top 50 by size
Bulk delete the clearly obsolete ones
Download and archive anything uncertain

After two or three cycles, the backlog of orphaned files is small enough that the quarterly review takes 15–20 minutes instead of hours.

Space-Level vs. Instance-Level Audits

Advanced Attachment Manager supports two scopes:

Space-level: Scope the view to a specific Confluence space. Useful for space owners doing routine maintenance on their own space.

Instance-level: Confluence admins can view attachments across the entire instance. This is the right starting point for a storage audit — see total consumption by space, identify which spaces are the biggest consumers, and then drill into each one.

A Note on Storage Recovery

After bulk deletion, Confluence doesn't immediately reclaim storage — deleted files go to Confluence trash first. A Confluence admin needs to empty the trash to release the storage.

Go to Confluence Administration → Trash → Empty Trash. After emptying, the storage reduction is reflected in your instance's storage usage.

Install Advanced Attachment Manager for Confluence →

How to Embed Interactive Charts in Confluence with HTML Macro

Yamuno — Tue, 16 Jun 2026 12:56:22 +0000

How to Embed Interactive Charts in Confluence with HTML Macro

Confluence is where a lot of teams track project status, document KPIs, and share team metrics. But when it comes to actually visualizing that data, the options are limited. You can paste a static image (which goes stale), use a third-party integration (which requires a separate subscription), or accept that your Confluence page just won't have charts.

HTML Macro for Confluence opens a fourth option: embed Chart.js directly inside a Confluence page. The charts are interactive (hover for tooltips, click to toggle series), render instantly, and live alongside your documentation — no external service required.

This guide covers four chart types with copy-paste code for each.

Before You Start

Install HTML Macro for Confluence from the Atlassian Marketplace. It's free and runs on Atlassian Forge.

Security note: The examples below load Chart.js from a CDN (cdn.jsdelivr.net). Your Confluence admin needs to add that domain to the HTML Macro whitelist. Go to Confluence Settings → HTML Macro → Security Settings and add https://cdn.jsdelivr.net to the allowed domains.

Once that's done, add the macro to any Confluence page (Insert → Macro → HTML Macro), paste the code, and use the live preview to verify it before saving.

Bar Chart — Team Metrics or Sprint Data

Good for: comparing values across categories — issues by status, story points per sprint, bugs per team member.

<canvas id="barChart" width="700" height="350"></canvas>
<script src="https://cdn.jsdelivr.net/npm/chart.js"></script>
<script>
  new Chart(document.getElementById('barChart'), {
    type: 'bar',
    data: {
      labels: ['To Do', 'In Progress', 'In Review', 'Done'],
      datasets: [{
        label: 'Issues',
        data: [12, 8, 5, 34],
        backgroundColor: ['#94a3b8', '#3b82f6', '#f59e0b', '#22c55e'],
        borderRadius: 6,
      }]
    },
    options: {
      responsive: false,
      plugins: {
        legend: { display: false },
        title: {
          display: true,
          text: 'Issue Status — Sprint 42',
          font: { size: 15, weight: '600' },
          color: '#1e293b',
        }
      },
      scales: {
        y: {
          beginAtZero: true,
          grid: { color: '#f1f5f9' },
          ticks: { color: '#64748b' }
        },
        x: {
          grid: { display: false },
          ticks: { color: '#64748b' }
        }
      }
    }
  });
</script>

Replace the labels and data arrays with your actual values. Each label maps to the corresponding data value by index.

Line Chart — Velocity Trend or Weekly Progress

Good for: showing trends over time — sprint velocity, bug discovery rate, weekly active users, anything with a time axis.

<canvas id="lineChart" width="700" height="350"></canvas>
<script src="https://cdn.jsdelivr.net/npm/chart.js"></script>
<script>
  new Chart(document.getElementById('lineChart'), {
    type: 'line',
    data: {
      labels: ['Sprint 37', 'Sprint 38', 'Sprint 39', 'Sprint 40', 'Sprint 41', 'Sprint 42'],
      datasets: [{
        label: 'Story Points Completed',
        data: [41, 38, 45, 52, 49, 55],
        borderColor: '#6366f1',
        backgroundColor: 'rgba(99, 102, 241, 0.08)',
        borderWidth: 2,
        pointBackgroundColor: '#6366f1',
        pointRadius: 4,
        fill: true,
        tension: 0.3,
      }]
    },
    options: {
      responsive: false,
      plugins: {
        legend: { position: 'top' },
        title: {
          display: true,
          text: 'Sprint Velocity — Last 6 Sprints',
          font: { size: 15, weight: '600' },
          color: '#1e293b',
        }
      },
      scales: {
        y: {
          beginAtZero: false,
          grid: { color: '#f1f5f9' },
          ticks: { color: '#64748b' }
        },
        x: {
          grid: { display: false },
          ticks: { color: '#64748b' }
        }
      }
    }
  });
</script>

Pie Chart — Issue Type or Priority Distribution

Good for: showing how a total is distributed — issue types, budget allocation, time spent by category. Keep it to five segments or fewer.

<canvas id="pieChart" width="500" height="400"></canvas>
<script src="https://cdn.jsdelivr.net/npm/chart.js"></script>
<script>
  new Chart(document.getElementById('pieChart'), {
    type: 'pie',
    data: {
      labels: ['Bug', 'Feature', 'Task', 'Tech Debt', 'Spike'],
      datasets: [{
        data: [18, 32, 25, 14, 11],
        backgroundColor: [
          '#ef4444',
          '#6366f1',
          '#3b82f6',
          '#f59e0b',
          '#94a3b8',
        ],
        borderWidth: 2,
        borderColor: '#fff',
      }]
    },
    options: {
      responsive: false,
      plugins: {
        legend: { position: 'right' },
        title: {
          display: true,
          text: 'Open Issues by Type',
          font: { size: 15, weight: '600' },
          color: '#1e293b',
        }
      }
    }
  });
</script>

Doughnut Chart — Goal Progress or Completion Status

Good for: showing a single metric against a target — sprint completion, budget consumed, onboarding progress.

<div style="position:relative; width:400px; margin:0 auto;">
  <canvas id="doughnutChart" width="400" height="400"></canvas>
  <div style="position:absolute; top:50%; left:50%; transform:translate(-50%,-50%); text-align:center; font-family:sans-serif;">
    <div style="font-size:36px; font-weight:700; color:#1e293b;">72%</div>
    <div style="font-size:13px; color:#64748b;">Complete</div>
  </div>
</div>
<script src="https://cdn.jsdelivr.net/npm/chart.js"></script>
<script>
  new Chart(document.getElementById('doughnutChart'), {
    type: 'doughnut',
    data: {
      datasets: [{
        data: [72, 28],
        backgroundColor: ['#6366f1', '#f1f5f9'],
        borderWidth: 0,
        cutout: '78%',
      }]
    },
    options: {
      responsive: false,
      plugins: {
        legend: { display: false },
        tooltip: { enabled: false },
      }
    }
  });
</script>

Change the 72 and 28 values (they must add to 100) and update the center label to match.

Multi-Dataset Line Chart — Compare Two Teams or Products

When you want to compare two data series on the same time axis:

<canvas id="multiLineChart" width="700" height="350"></canvas>
<script src="https://cdn.jsdelivr.net/npm/chart.js"></script>
<script>
  new Chart(document.getElementById('multiLineChart'), {
    type: 'line',
    data: {
      labels: ['Week 1', 'Week 2', 'Week 3', 'Week 4', 'Week 5', 'Week 6'],
      datasets: [
        {
          label: 'Team Alpha',
          data: [12, 19, 15, 22, 18, 25],
          borderColor: '#6366f1',
          backgroundColor: 'transparent',
          borderWidth: 2,
          pointRadius: 4,
          tension: 0.3,
        },
        {
          label: 'Team Beta',
          data: [8, 14, 20, 17, 24, 21],
          borderColor: '#22c55e',
          backgroundColor: 'transparent',
          borderWidth: 2,
          pointRadius: 4,
          tension: 0.3,
        }
      ]
    },
    options: {
      responsive: false,
      plugins: {
        legend: { position: 'top' },
        title: {
          display: true,
          text: 'Weekly Issues Resolved',
          font: { size: 15, weight: '600' },
          color: '#1e293b',
        }
      },
      scales: {
        y: { beginAtZero: true, grid: { color: '#f1f5f9' } },
        x: { grid: { display: false } }
      }
    }
  });
</script>

Tips for Production Use

Hard-code the data for now. Chart.js in Confluence can't call your Jira API or database — the data lives in the HTML. If your metrics change weekly, treat the Confluence page as a weekly snapshot: update the arrays when you update the commentary.

Use width and height attributes directly on <canvas>. Don't rely on responsive: true inside Confluence — the macro iframe has fixed dimensions and responsive sizing can behave unexpectedly.

Each chart needs a unique id. If you put multiple charts on the same page, give each canvas a different id (barChart, lineChart, etc.) to avoid conflicts.

Test in the live preview before saving. HTML Macro's side-by-side preview shows you exactly what Confluence page visitors will see — including CDN scripts loading.

A Note on the CDN Whitelist

Your admin needs to whitelist https://cdn.jsdelivr.net in HTML Macro's security settings for the Chart.js scripts to load. If the charts appear blank, that's the most common cause. Check the browser console for a CSP error and confirm the domain is in the allowlist.

For environments where all external CDNs are blocked, you can paste the minified Chart.js source directly into the <script> tag — it's about 60KB minified, which is manageable.

Install HTML Macro for Confluence — free on the Atlassian Marketplace

How to Sync Docs from GitHub to Confluence Automatically

Yamuno — Wed, 10 Jun 2026 11:40:41 +0000

How to Sync Docs from GitHub to Confluence Automatically

Documentation drift is one of the most common problems in engineering teams. The markdown files in your GitHub repo are accurate — they're updated as part of the same PR that changes the code. The Confluence pages that were supposed to mirror them were last updated six months ago by someone who has since left the team.

This guide shows how to wire GitHub and Confluence together so your repo is the single source of truth and Confluence stays in sync automatically, without anyone manually copying content between the two.

The Setup

The approach uses the Markdown Importer for Confluence REST API combined with a GitHub Actions workflow. When a push lands on your main branch, the workflow calls the API to import the updated markdown files into the right Confluence pages.

You need:

Markdown Importer for Confluence installed on your Confluence Cloud instance
A Confluence API token
A GitHub repository with markdown documentation

Step 1 — Generate a Confluence API Token

Go to id.atlassian.com/manage-profile/security/api-tokens
Click Create API token
Give it a name ("GitHub Actions — Confluence Sync")
Copy the token immediately — it's only shown once

Store it as a GitHub Actions secret: CONFLUENCE_API_TOKEN. Also store your Confluence email as CONFLUENCE_EMAIL and your Confluence base URL as CONFLUENCE_BASE_URL.

Step 2 — Find the Target Page ID

Each import needs a target Confluence page ID — the parent page where the markdown will be created or updated.

To find a page ID:

Open the target Confluence page
Click ••• → Page Information
The ID is in the URL: ...confluence/pages/edit-v2/123456789

Or use the Confluence REST API:

GET https://your-instance.atlassian.net/wiki/rest/api/content?title=Your+Page+Name&spaceKey=YOURSPACE

Store the page ID as a GitHub Actions variable (CONFLUENCE_PAGE_ID).

Step 3 — Create the GitHub Actions Workflow

Create .github/workflows/sync-docs-to-confluence.yml:

name: Sync Docs to Confluence

on:
  push:
    branches:
      - main
    paths:
      - 'docs/**'

jobs:
  sync:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Zip docs folder
        run: zip -r docs.zip docs/

      - name: Import to Confluence
        run: |
          curl -X POST \
            "https://your-instance.atlassian.net/wiki/rest/api/content/${{ vars.CONFLUENCE_PAGE_ID }}/child/page" \
            -u "${{ secrets.CONFLUENCE_EMAIL }}:${{ secrets.CONFLUENCE_API_TOKEN }}" \
            -H "Content-Type: multipart/form-data" \
            -F "file=@docs.zip" \
            -F "pageHierarchy=true" \
            -F "overwrite=true"

The paths filter means the workflow only triggers when files inside docs/ change — not on every push to main.

Step 4 — Use the Markdown Importer REST API Directly

The Markdown Importer REST API gives you more control than the UI. The key endpoint for automation:

POST /wiki/rest/atlassian-connect/1/addons/com.yamuno.markdown-importer/resources/api/import

Request body (multipart/form-data):

Field	Value
`file`	ZIP archive of markdown files
`parentPageId`	Target parent page ID
`spaceKey`	Target Confluence space key
`pageHierarchy`	`true` to preserve folder structure as page hierarchy
`overwrite`	`true` to update existing pages instead of creating duplicates

Authentication: HTTP Basic — email + API token.

A more complete workflow that handles individual files:

#!/bin/bash
# sync-to-confluence.sh

BASE_URL="${CONFLUENCE_BASE_URL}"
EMAIL="${CONFLUENCE_EMAIL}"
TOKEN="${CONFLUENCE_API_TOKEN}"
PAGE_ID="${CONFLUENCE_PAGE_ID}"
SPACE_KEY="${CONFLUENCE_SPACE_KEY}"

# Create ZIP from docs folder
zip -r docs.zip docs/

# Call the import API
curl -s -X POST \
  "${BASE_URL}/wiki/rest/atlassian-connect/1/addons/com.yamuno.markdown-importer/resources/api/import" \
  -u "${EMAIL}:${TOKEN}" \
  -F "file=@docs.zip" \
  -F "parentPageId=${PAGE_ID}" \
  -F "spaceKey=${SPACE_KEY}" \
  -F "pageHierarchy=true" \
  -F "overwrite=true" \
  | jq '.'

Step 5 — Preserve Folder Structure as Confluence Hierarchy

If your docs folder looks like this:

docs/
├── getting-started.md
├── installation.md
├── how-to/
│   ├── first-steps.md
│   └── advanced-usage.md
└── reference/
    ├── api.md
    └── config.md

With pageHierarchy=true, the importer creates a matching Confluence page tree:

Getting Started
Installation
How To
  ├── First Steps
  └── Advanced Usage
Reference
  ├── API
  └── Config

Each folder becomes a parent page. The markdown file names become page titles (with hyphens replaced by spaces and the first letter capitalized).

Step 6 — Handle Frontmatter

Markdown Importer reads YAML frontmatter and uses it to set page metadata:

---
title: "API Reference"
---

If a title field is present, the importer uses it as the Confluence page title instead of the filename. This lets you have api.md in the repo but "API Reference" as the Confluence page title.

Other frontmatter fields are ignored for the import but preserved if you export back to markdown.

Testing the Workflow

Push a small change to a doc file on main and watch the Actions tab in GitHub. The workflow should:

Trigger on the push event
Zip the docs folder
Call the import API
Return a 200 with the list of pages created or updated

Check Confluence to confirm the pages reflect the changes. The first import creates the pages; subsequent imports update them in place (because overwrite=true).

Common Patterns

Sync only changed files: Use git diff --name-only HEAD~1 HEAD -- docs/ in the workflow to identify which files changed, then import just those files instead of the full folder. Faster and avoids unnecessary Confluence page updates.

Multiple doc sources: Run the import step multiple times with different source folders and target page IDs. You can sync docs/public/ to a customer-facing space and docs/internal/ to an internal space in the same workflow.

Preview before merging: Add the sync workflow to pull request branches targeting a staging Confluence space. Reviewers can check how the docs render in Confluence before the PR merges.

Result

Once the workflow is running, your documentation process is:

Edit markdown in the repo
Open a PR, get it reviewed, merge
Confluence updates automatically within minutes

No manual copying. No drift. The engineers writing the code are the same people keeping the docs current — because it's the same commit.

Install Markdown Importer for Confluence →

Read the REST API documentation →

How to Create Custom PDF Templates in Confluence

Yamuno — Sat, 06 Jun 2026 10:07:14 +0000

How to Create Custom PDF Templates in Confluence

If your team exports Confluence pages to PDF regularly, you've probably run into this problem: every export looks different. One person adds a cover page, another doesn't. Headers are inconsistent. Some PDFs have page numbers, others don't. When the document goes to a client or a regulator, it looks like it came from three different organizations.

The fix is a shared template. Create it once, and every export from the instance uses it automatically — no manual configuration each time.

This guide covers how to set up PDF export templates in Confluence using PDF Exporter for Confluence.

Prerequisites

PDF Exporter for Confluence installed from the Atlassian Marketplace
Confluence admin access (templates are configured in Confluence Settings)

Regular users can apply templates but cannot create or edit them.

Step 1 — Open Template Management

Go to Confluence Settings (gear icon, top-right)
In the left sidebar, find PDF Exporter
Click Templates

You'll see the template list. New instances have three built-in templates: Default, Report, and Minimal. You can edit these or create new ones.

Step 2 — Create a New Template

Click New Template and give it a name. Use something descriptive — "Client Deliverable," "Internal Report," "Compliance Archive" — so team members know which template to pick.

Add an optional description explaining when to use this template.

Step 3 — Configure Page Layout

Under Page Layout, set:

Page Size — A4 for international use, Letter for North America, Legal for formal legal documents
Orientation — Portrait for most documentation, Landscape for wide tables or diagrams
Font Size — Medium is the default and works for most use cases; Large if the document will be read on screen rather than printed

Step 4 — Set Up the Cover Page

Cover pages are one of the most visible differences between a professional-looking PDF and a bare export. Turn them on under Cover Page.

Style options:

Style	When to use
Classic	General internal documents
Corporate	Client-facing deliverables with a formal tone
Modern	Product documentation with a contemporary feel
Executive	Board reports, executive summaries
Bold	Team-facing reports where visual impact matters
Minimal	When you only need the title and author, no decoration

Customization:

Accent Color — set a hex value to match your brand palette. The default is Yamuno purple (#504DC4); change it to your company's primary color
Subtitle — optional text below the page title (e.g., "Confidential — Not for Distribution" or "Version 2.1")
Author — appears on the cover. Use a team name ("Solutions Engineering") rather than a person's name if the template will be shared
Logo — upload a PNG, JPG, or SVG. The logo is stored per template and appears on the cover automatically

The template editor shows a live preview as you configure, so you can see exactly how the cover will look before saving.

Step 5 — Configure Headers and Footers

Headers and footers appear on every content page (not the cover).

Header:

Enable it and add text — typically a document title, project name, or team name
Position: Left, Center, or Right

Footer:

Enable it and add text — typically a confidentiality notice, date, or department name
Position: Left, Center, or Right

Page Numbers:

Enable separately from the footer
Format options: 1, 1 / 10, or Page 1 of 10
Position: Left, Center, or Right

A common layout: document title centered in the header, page numbers right-aligned in the footer, confidentiality notice left-aligned in the footer.

Step 6 — Add a Watermark (Optional)

Watermarks are useful for draft reviews, confidential documents, or compliance archives.

Enable Watermark, enter the text (e.g., "DRAFT," "CONFIDENTIAL," "FOR REVIEW ONLY"), and set the opacity. The default opacity of 0.15 is visible without dominating the content. Go lower for a more subtle mark, higher if the watermark needs to be unmissable.

Step 7 — Table of Contents

For multi-page exports, a table of contents makes the document navigable.

Enable Table of Contents and set the depth:

Depth 1: H1 headings only
Depth 2: H1 and H2
Depth 3: H1, H2, and H3

For technical documentation, Depth 2 is usually the right balance. Depth 3 can make the TOC longer than some sections.

Step 8 — Page Breaks

Under Page Breaks, you can configure the exporter to insert automatic page breaks before H1 and/or H2 headings. This keeps major sections starting on a fresh page, which looks significantly cleaner in multi-topic exports.

Enable "Break before H1" at minimum. Enable "Break before H2" for documents with long subsections.

Step 9 — Save and Test

Click Save. The template is immediately available to all users on the Confluence instance.

To verify it works:

Navigate to any Confluence page
Click ••• → Export to PDF
Select your new template from the dropdown
Use the Preview option before downloading

Check the cover page, headers, and watermark. If anything looks off, go back to Settings → PDF Exporter → Templates → Edit.

Managing Multiple Templates

For most teams, two or three templates covers the range of use cases:

Client-facing — cover page (Corporate style), branded header, confidentiality footer, page numbers, no watermark
Internal draft — cover page (Minimal), watermark "DRAFT," page numbers
Compliance archive — cover page (Executive), watermark "ARCHIVED," page numbers, department footer

Archive templates you no longer want used (rather than deleting them) — the Archive option hides them from user dropdowns while preserving the settings for reference.

Result

Once your templates are set up, the export workflow for every user is:

Open the page → ••• → Export to PDF
Pick a template
Click Export

No formatting decisions. No inconsistent output. The same cover, the same header, the same page layout — every time.

Install PDF Exporter for Confluence →

Read the documentation →

Best Jira Dashboard Widgets and Charts in 2026

Yamuno — Tue, 02 Jun 2026 12:06:39 +0000

Best Jira Dashboard Widgets and Charts in 2026

Most Jira dashboards fail the same way: too many gadgets, none of them useful. A pie chart of issue types nobody asked for. A filter results table showing 200 tickets. A sprint burndown that's three sprints out of date.

The best dashboards answer one or two specific questions for a specific audience. This guide covers the widgets and chart types that consistently deliver value — and the setups that make them useful in practice.

The Right Frame Before You Start

Before picking any widget, decide who the dashboard is for and what decision it needs to support.

A dashboard for a sprint team answers: "Are we on track this week?" It needs velocity, blocked issues, and scope change.

A dashboard for an engineering manager answers: "Where are the bottlenecks?" It needs cycle time, work in progress by assignee, and escalated bugs.

A dashboard for a product stakeholder answers: "What shipped and what's coming?" It needs release status, feature progress, and open defects.

If you try to serve all three audiences on one dashboard, you serve none of them.

Bar Chart — Issue Distribution by Status or Assignee

Best for: Sprint planning, workload reviews, standup summaries.

A bar chart with issues grouped by status (To Do / In Progress / In Review / Done) gives you the distribution at a glance. When combined with a sprint or fix version filter, it answers "where is everything right now?" in one view.

Grouped by assignee, the same chart becomes a workload visualization. If one person has 18 open issues and another has 3, that's visible immediately — no one needs to pull a report.

Setup in Charts for Jira Dashboard:

Chart type: Bar
Group by: Status or Assignee
Filter: Current sprint or active fix version
Orientation: Horizontal for assignee view (names read better)

Line Chart — Velocity Trend Over Time

Best for: Sprint retrospectives, capacity planning, stakeholder updates.

A single sprint's velocity is nearly meaningless. A six-sprint trend tells you whether the team is improving, declining, or stable. That context is what makes capacity planning possible.

Set the X-axis to sprint and the Y-axis to story points completed. Add a trend line. The slope tells you more than any individual data point.

What to avoid: Reporting velocity in isolation without noting team size changes. A jump in velocity after two people joined isn't an improvement — it's headcount. Track points per person if you want a clean signal.

Setup:

Chart type: Line
X-axis: Sprint
Y-axis: Story points (completed)
Enable: Trend line
Filter: Last 6–8 sprints

Pie Chart — Issue Type or Priority Breakdown

Best for: Bug triage, backlog health checks, executive summaries.

Pie charts are often overused but have a legitimate place for proportion data. The question "what percentage of open work is bugs vs. features vs. tech debt?" is a proportion question — a pie chart answers it directly.

Keep it to five slices or fewer. Beyond that, the chart becomes a color matching exercise.

Setup:

Chart type: Pie
Group by: Issue type or Priority
Filter: Open issues in the relevant project
Labels: Show percentages

Area Chart — Cumulative Flow

Best for: Identifying bottlenecks, WIP limit enforcement, kanban teams.

A cumulative flow diagram shows how issues accumulate and drain through each status over time. When one band (say "In Review") grows noticeably wider, it means work is piling up there — a bottleneck you can address before it delays the sprint.

This is the most analytically powerful chart on this list and the one teams are most likely to underuse.

Setup:

Chart type: Area (stacked)
X-axis: Date
Y-axis: Issue count
Group by: Status
Filter: Active sprint or last 30 days

Scatter Chart — Effort vs. Completion Time

Best for: Estimation calibration, cycle time analysis.

Plot story points on the X-axis and actual days to complete on the Y-axis. Each issue is a dot. What you're looking for: are small-point issues actually completing faster? Are there outliers — high-point issues that took surprisingly little time, or vice versa?

This chart is most useful for teams trying to improve their estimation accuracy. After a few sprints, the pattern (or lack of one) tells you whether your point scale correlates with actual effort.

Setup:

Chart type: Scatter
X-axis: Story points
Y-axis: Cycle time (days)
Filter: Completed issues, last 3 months

Table View — Blocked Issues and Escalations

Best for: Daily standup, impediment tracking, management escalation.

Sometimes you don't need a visualization — you need a list. A table filtered to "Blocked" issues with columns for assignee, block reason, and days blocked is more actionable in a standup than any chart.

Setup:

View type: Table
Filter: Status = Blocked, or Label = "escalated"
Columns: Issue key, Summary, Assignee, Days open
Sort: Days open (descending)

One Dashboard, One Audience

The practical setup that works: one dashboard per team type, pinned as the default for that team's Jira project.

Sprint team: Velocity line + status bar + blocked table
Engineering manager: Workload bar + cumulative flow area + cycle time scatter
Product stakeholder: Release progress bar + priority pie + escalation table

Each dashboard has three gadgets. Three is usually enough. If you need a fourth, something on the existing board isn't earning its space.

Getting Started

Charts - Reports and Graphs for Jira Dashboard is available on the Atlassian Marketplace. Add it to any Jira dashboard gadget, choose your chart type, connect it to a project or JQL filter, and it renders immediately from your live Jira data.

Install Charts for Jira Dashboard →

How Finance Teams Document Quantitative Models in Confluence

Yamuno — Fri, 29 May 2026 11:32:11 +0000

How Finance Teams Document Quantitative Models in Confluence

Most quantitative model documentation is a mess — not because quants don't care about documentation, but because the tools for writing math and the tools for sharing knowledge with a team don't overlap.

The model lives in Python or R. The derivations live in a LaTeX PDF that took three days to write and is now orphaned in a shared drive folder nobody navigates. The assumptions are in a Word document last edited in 2023. The backtesting results are in Excel. A new analyst joining the team has to reconstruct the model's intent by reading code comments and asking questions.

Confluence is where team knowledge should live. But until recently, Confluence had no good way to write actual math — which meant quant teams had the choice between prose approximations that lose precision, or screenshots of equations that become wrong the moment the model changes.

What Quantitative Model Documentation Should Include

Good model documentation isn't just the formula. It's the context that makes the formula meaningful to someone who didn't build it.

Model purpose and scope — what decision this model informs, what asset class or portfolio it applies to, and what it explicitly does not cover. This section is often skipped and is often the most important.

Assumptions — every model has them. Write them down explicitly. Which distributional assumptions are you making? What market conditions does the model assume? Where does it break down?

Formula derivation — the derivation from first principles, or a clear reference to where that derivation lives. Not just the final formula, but why it takes that form.

Input and output specification — what goes in, what comes out, what units, what frequency, what data sources. A table is cleaner than prose here.

Backtesting and validation results — summary statistics, time period, benchmark comparison. These change as you re-run validation; note the date.

Limitations and known failure modes — where the model underperforms, what conditions make it unreliable, what it should not be used for. This is the section that protects the team.

Version and change history — when the model was last updated, what changed, and why.

Writing Formulas in Confluence with LaTeX

LaTeX Math for Confluence adds a /latex macro to Confluence that renders LaTeX equations live on the page. Type the macro, write the LaTeX source, and the rendered equation appears — inline or as a block. No screenshots, no external editors, no export-and-upload cycle.

Here's what real quant model documentation looks like with it.

Option Pricing: Black-Scholes

The Black-Scholes formula for a European call option:

C = S_0 \, N(d_1) - K e^{-rT} N(d_2)

Where:

d_1 = \frac{\ln(S_0 / K) + (r + \tfrac{1}{2}\sigma^2)T}{\sigma\sqrt{T}}
\qquad
d_2 = d_1 - \sigma\sqrt{T}

And $N(\cdot)$ is the standard normal CDF. Documenting the variable definitions inline is straightforward — you can mix inline LaTeX like $S_0$ (current price), $K$ (strike), $r$ (risk-free rate), $\sigma$ (volatility), $T$ (time to expiry) into a paragraph without switching formats.

Portfolio Risk: Variance and Volatility

Portfolio variance for a two-asset portfolio:

\sigma_p^2 = w_1^2 \sigma_1^2 + w_2^2 \sigma_2^2 + 2 w_1 w_2 \sigma_1 \sigma_2 \rho_{12}

Generalised to $n$ assets using the covariance matrix $\Sigma$:

\sigma_p^2 = \mathbf{w}^\top \Sigma \, \mathbf{w}

Where $\mathbf{w}$ is the vector of portfolio weights. This is the kind of expression that, written in plain text, requires three sentences to explain what a single line of math conveys unambiguously.

Performance Metrics: Sharpe and Sortino Ratios

Sharpe ratio:

S = \frac{\mathbb{E}[R_p - R_f]}{\sigma_p}

Sortino ratio, which penalises only downside volatility:

\text{Sortino} = \frac{\mathbb{E}[R_p - R_f]}{\sigma_d}
\qquad
\sigma_d = \sqrt{\mathbb{E}\left[\min(R_p - R_f,\, 0)^2\right]}

Documenting both on the same page with their formulas makes clear why you might prefer one over the other for a strategy with asymmetric return distributions — which is precisely the kind of reasoning that should be captured in model documentation.

Risk Models: Value at Risk

Parametric VaR at confidence level $\alpha$:

\text{VaR}_\alpha = \mu_p - z_\alpha \, \sigma_p

Historical simulation VaR — defined as the $(1-\alpha)$ quantile of the empirical return distribution ${r_t}_{t=1}^T$:

\text{VaR}_\alpha = -Q_{1-\alpha}\left(\{r_t\}\right)

Conditional VaR (Expected Shortfall):

\text{CVaR}_\alpha = -\mathbb{E}\left[R \mid R \leq -\text{VaR}_\alpha\right]

These three measures are often discussed together but have meaningfully different properties in tail events. Having all three on one page with their exact definitions eliminates the ambiguity that shows up in verbal descriptions.

Fixed Income: Duration and Convexity

Modified duration:

D_{mod} = -\frac{1}{P} \frac{dP}{dy} = \frac{D_{mac}}{1 + y/m}

Where $D_{mac}$ is Macaulay duration, $y$ is yield to maturity, and $m$ is the number of coupon periods per year.

Convexity:

C = \frac{1}{P} \frac{d^2P}{dy^2}

Price change approximation incorporating both:

\frac{\Delta P}{P} \approx -D_{mod} \cdot \Delta y + \frac{1}{2} C \cdot (\Delta y)^2

Structuring a Model Documentation Page in Confluence

A consistent page template makes model docs easier to write and easier to audit. Here's a structure that works:

Model: [Model Name]
├── 1. Overview
│   ├── Purpose
│   ├── Scope and applicable instruments
│   └── Owner and last review date
├── 2. Assumptions
│   └── Numbered list — be specific
├── 3. Model Specification
│   ├── Notation table (define every symbol)
│   ├── Derivation (or reference)
│   └── Final formula(s) as block equations
├── 4. Inputs and Outputs
│   └── Table: variable, type, source, frequency
├── 5. Implementation Notes
│   ├── Code reference (link to repo/file)
│   └── Numerical considerations (overflow, precision)
├── 6. Validation and Backtesting
│   ├── Methodology
│   ├── Time period
│   └── Results summary (table)
├── 7. Limitations
│   └── Explicit failure modes
└── 8. Change Log
    └── Date | Change | Author

The notation table in section 3 is often skipped and almost always needed. Every symbol used in the formulas should appear in a table with its definition, units, and typical range. A reader who wasn't in the original modelling sessions shouldn't have to guess what $\lambda$ refers to.

Keeping Model Documentation Up to Date

Model documentation drifts for the same reason all documentation drifts: updating it is a separate step from updating the model.

A few practices that help:

Treat the Confluence page as part of the model. Link to it from the code repository — a comment in the main model file pointing to the Confluence page URL. When a developer opens the file to make changes, the docs link is visible.

Add a documentation review step to your model validation process. Most quant teams already have a formal model validation workflow. Add a checkpoint: has the Confluence page been updated to match the current implementation?

Use the change log section. It doesn't need to be exhaustive — a one-line entry per model update (date, what changed, who changed it) is enough to give future readers context. This is much cheaper to maintain than reconstructing history from git blame.

Keep equations as LaTeX source, not images. The point of using LaTeX Math for Confluence is that the source is editable in place. When a formula changes, you edit the LaTeX directly on the Confluence page — two minutes of work, not an export-and-upload cycle. That lower friction is what makes it realistic to keep docs in sync.

Getting Started

Install LaTeX Math for Confluence from the Atlassian Marketplace. On any Confluence page, type /latex to insert a block equation or use the inline variant for in-paragraph math.

Full documentation is at LaTeX Math for Confluence docs.

Questions? Reach out via our support portal.

How to Use Confluence as a Developer Wiki

Yamuno — Sat, 23 May 2026 09:56:30 +0000

How to Use Confluence as a Developer Wiki

Confluence has a reputation problem with developers. It's slow. The editor is clunky. Markdown support used to be nonexistent. Half the team wants to write docs in GitHub, the other half uses Notion, and Confluence ends up as a graveyard of stale meeting notes and quarterly plans nobody reads.

That reputation is partially deserved and partially outdated. There are cases where Confluence is genuinely the right choice for a developer wiki — and when it is, there's a right way to set it up so developers will actually use it.

When Confluence Makes Sense for Developers

Don't reach for Confluence just because your company already has a license. Use it when these conditions are true:

Your team already uses Jira. The Jira ↔ Confluence integration is genuinely useful — linking a runbook to an incident, embedding a sprint's Jira issues in a planning page, referencing an ADR from a ticket. If your team lives in Jira, having docs one click away is real value.

You need docs linked to project history. GitHub wikis are disconnected from non-code work. Notion has no Jira integration worth mentioning. Confluence lets you tie documentation to the projects, releases, and sprints that produced it.

Compliance or audit requirements exist. If your team needs documented approval workflows, page history with authors and timestamps, or access controls on specific documentation, Confluence handles this natively. Most alternatives don't.

Your organization is large enough that discoverability matters. In a 10-person team, everyone knows where docs live. In a 200-person engineering organization, cross-team search across a unified Confluence instance is worth a lot. Fragmented Notion workspaces and GitHub wikis across dozens of repos don't have that.

If none of these apply, Notion or a docs-as-code approach (MDX files in a repo, rendered with a tool like Docusaurus) is probably the better call. Confluence is not the right tool for every team.

How to Structure a Developer Wiki in Confluence

The most common failure mode is dumping everything into one space with no structure. Within a year it's unsearchable. The second failure mode is over-structuring — five levels of nesting that nobody can navigate.

A practical structure for an engineering team's Confluence space:

Engineering (space root)
├── Onboarding
│   ├── New Engineer Setup
│   ├── Development Environment
│   ├── Access & Permissions Request
│   └── First Week Checklist
├── Architecture
│   ├── System Overview
│   ├── Architecture Decision Records (ADRs)
│   │   ├── ADR-001: Use PostgreSQL for primary storage
│   │   ├── ADR-002: Adopt event-driven architecture
│   │   └── ADR-003: ...
│   └── Data Flow Diagrams
├── Services
│   ├── auth-service
│   │   ├── Overview & Runbook
│   │   ├── API Reference
│   │   └── Known Issues
│   └── payments-service
│       └── ...
├── Runbooks
│   ├── Incident Response
│   ├── Database Failover
│   ├── Deployment Rollback
│   └── On-Call Handoff Template
├── Incident Postmortems
│   ├── 2026-04-12 Payment Processing Outage
│   └── 2026-03-07 Auth Service Latency Spike
└── Release Notes
    └── (one page per release or sprint)

A few principles behind this structure:

Runbooks get their own section — not buried under individual services. When something is on fire at 2am, you want fast access without knowing which service owns the runbook.

ADRs live in Architecture and follow a consistent template (context, decision, consequences). They're written once and rarely updated — that's fine, they're meant to capture a decision at a point in time.

Incident Postmortems are first-class content. Don't hide them or let them expire. They're the most valuable institutional knowledge a team produces.

Services have a lightweight, consistent structure — not every possible sub-page, just overview, runbook, and API reference at minimum.

Making Confluence Actually Dev-Friendly

The editor is where most developers tap out. The default Confluence editor is fine for business users writing prose, but it's friction for developers who think in markdown.

Markdown support. Markdown Renderer for Confluence lets you write and maintain Confluence pages in pure markdown — including fenced code blocks with syntax highlighting, tables written as markdown tables, and inline formatting that looks exactly like it does in a README. No dealing with the visual editor for technical content.

Importing existing docs. If your team already has markdown documentation in a GitHub repo or a folder of .md files, Markdown Importer for Confluence can pull those in directly — preserving heading hierarchy, code blocks, internal links, and images — without a manual copy-paste operation for each file. For teams migrating from a GitHub wiki or a docs folder, this is the fastest path.

Code blocks. Confluence has native code block macros. Use them. Always specify the language. Unformatted terminal output and code snippets in regular text boxes are unusable.

Labels and page properties. Use labels consistently (e.g., runbook, adr, postmortem, service:auth) and you get free filtering. The Confluence built-in page properties macro lets you build tables that auto-populate from child pages — useful for a service catalog or ADR index.

What Not to Do

Don't put everything in Confluence. Real-time communication belongs in Slack. Code review discussion belongs in GitHub. Work-in-progress thinking belongs in personal notes. Confluence is for stable, findable reference material — runbooks, specs, decisions, and onboarding docs. If it's likely to change daily, it probably shouldn't be in Confluence.

Don't create pages without linking them to Jira. The Jira integration is the main reason to choose Confluence over alternatives. If you're writing an ADR for a significant architecture decision, link it to the epic. If you're writing a runbook for a service, link the relevant Confluence page from the Jira project. Orphaned documentation gets stale because nobody finds it.

Don't make pages too long. Confluence has no natural incentive to keep pages short. A 10,000-word page that should be five linked pages is common and terrible. If you're scrolling for more than two screens to find what you need, split the page.

Don't treat Confluence as a ticket system. Action items and tasks go in Jira. Using Confluence pages to track work that should be in a Jira board is how you end up with two half-maintained systems instead of one.

An Honest Assessment

Confluence is a real tradeoff. The editor is slower than a markdown file in VS Code. Search is good but not great for code snippets. Free-tier teams will find the cost steep. And it requires active maintenance — without someone periodically reviewing and archiving stale pages, it degrades into a documentation graveyard.

What it's genuinely better at: stable, findable reference documentation for teams inside larger organizations that already run Jira. If that describes your situation, invest in a clear structure from day one, get markdown support in place so developers don't fight the editor, and keep the scope tight. A small, well-maintained Confluence space beats a large, neglected one every time.

Questions? Reach out via our support portal.