How to Share Jira Time in Status Reports in Confluence

[#1]

Every team hits this wall sooner or later.

You’ve got a solid "Time in Status" report that actually gives you the real picture—bottlenecks, wait times, and whether your delivery is speeding up or dragging.

The catch? Your weekly updates live in Confluence. Your retros happen there, too. Same goes for stakeholder summaries and QBR drafts.

So what ends up happening? Someone spends time manually copying numbers, drops in a screenshot, or just pastes a link and crosses their fingers that people will click it.

Spoiler: they usually don’t.

It’s not that the report is bad. It’s just trapped somewhere else, completely disconnected from where the actual conversations are happening.

This article looks at:

• why Confluence matters so much for delivery reporting,
• what changes as the JSON Data Feed is retired,
• the direction we're taking to bring reports back into Confluence.

Why Confluence Is Where Delivery Reporting Actually Happens

For most enterprise teams, Confluence isn't just documentation.

It's where the delivery rituals live:

• sprint reviews,
• retrospectives,
• release updates,
• stakeholder reporting,
• QBRs,
• operational reviews,
• team health pages,
• and SLA or incident review notes.

Time in Status answers the workflow questions. Confluence is where those answers turn into decisions:

• Where did work wait the longest this sprint?
• Which statuses are creating delays?
• Did our workflow change actually improve delivery?
• Which team or queue needs attention?
• Are we meeting our internal SLA expectations?

When the report lives on the page, the gap between "here's the data" and "here's what we'll do" almost disappears.

No tab-switching. No stale screenshots. No "let me find that link."

What's Changing: the JSON Data Feed Is Being Retired

Some teams previously brought Time in Status reports into Confluence using the JSON Data Feed — generating a feed link from a preset and pasting it into a Confluence macro.

As the JSON Data Feed is retired and replaced with a new API, that particular path no longer works the way it used to.

For teams that had standardized their reporting around Confluence, that creates real friction:

• reports can't be included where stakeholders already read updates,
• people fall back to copying data manually,
• a familiar reporting flow disappears,
• delivery pages become less data-driven,
• and reporting rituals get harder to maintain.

If your team had already built its cadence around Confluence pages, this is the part that hurts most.

So the question becomes: how do we bring trusted reports back into Confluence — cleanly?

The Direction We're Taking: Report Presets in Confluence

Time in Status lets you share report presets in Confluence using Atlassian cross-context.

Here's how it works:

Set up the preset you need in the Time in Status app, then add it to your Confluence page.

Instead of rebuilding the same report by hand on every page, teams reuse a configuration they already trust.

The first iteration focuses on:

• sharing saved report presets in Confluence,
• using Atlassian cross-context,
• preserving the preset's configuration,
• supporting the way teams already communicate,
• and reducing disruption for customers who previously relied on the Data Feed.

In practice, that means the report you carefully set up — period, report type, calendar, columns, filters, workflow groupings — is the exact report your stakeholders see on the page.

How to Add a Time in Status Report to a Confluence Page

It only takes a moment once your preset is ready.

Before you start, make sure that:

• Confluence is added in your Connections (Manage Apps),
• you have access to the Confluence page,
• you have access to Time in Status app,
• and you already have a saved report (preset).

Then, on the page:

1. Open the Confluence page and select Edit.
2. Insert a macro and search for Time in Status Report.

1. Select the macro — a configuration window opens.
2. Open the Preset selector, choose your saved report, and select Save.

 

That's it. The report renders directly on the page, using the preset's saved configuration — report type, columns, format, and work schedule — along with the current work-item count.

On the page, you can:

• sort columns,
• group data,
• apply filters,
• and refresh to pull the latest data from Jira.

What stays in Time in Status: report type, columns, format, work schedule, date interval, chart type, JQL, and export settings. To change any of those, update the preset in the app, then refresh the report on the page. Presets can't be created, edited, or deleted from Confluence — which is exactly what keeps the shared view stable.

One more thing worth noting: the embedded report retrieves data through Atlassian cross-product APIs and respects both Jira and Time in Status permissions, so people only ever see the data they're already allowed to see.

Why We're Starting With Presets

Enterprise reporting depends on consistency.

If every Confluence page uses a slightly different configuration, the numbers stop being comparable — and stop being trusted.

Saved presets solve this because the report logic is defined once in Time in Status.

That lets teams align on a single definition of:

• report period,
• report type,
• calendar,
• columns,
• filters,
• chart/table setup,
• and workflow (status) definitions.

Then the same preset is reused in Confluence.

In this first iteration, report settings won't be edited directly inside Confluence. That's deliberate — it keeps the shared report stable and avoids configuration drift across pages.

Time in Status is where you configure and maintain the report. Confluence is where your team consumes and discusses it.

The Plan: Presets First, More Control Later

This first version is intentional, not incomplete. The plan builds outward:

• Iteration 1 — Presets in Confluence. Add saved Time in Status presets to any page.
• Iteration 2 — Dynamic periods. More flexible date ranges where they make sense.
• Iteration 3 — More report controls. More configuration available directly from the Confluence context.

Starting with stable, trusted presets means teams can re-establish their reporting flow first, then gain flexibility as it arrives.

Who Will Benefit Most

Delivery Leads — include workflow reports in recurring status pages.

Scrum Masters — bring sprint and cycle-time insights straight into retrospectives.

Engineering Managers — share bottlenecks and workload trends with stakeholders, in context.

Jira Admins — standardize reporting through saved presets instead of one-off screenshots.

PMO / Operations teams — keep delivery reporting consistent across teams and programs.

What Better Reporting Will Look Like for Your Team

You'll know this is working when:

• delivery pages stay data-driven, with live reports instead of pasted numbers,
• the same trusted preset shows up across status pages, retros, and SLA reviews,
• manual copying and screenshotting quietly disappear from your routine,
• and Confluence stays the place where delivery conversations happen — now backed by current data.

Final Thoughts

Time in Status reports help teams understand how work moves through Jira.

Confluence helps teams communicate, document, and decide what to do next.

Bringing report presets into Confluence connects those two moments.

The direction is a simple but important one: share trusted Time in Status presets exactly where your team already discusses delivery.

Less manual copying.

Fewer screenshots.

More reliable delivery conversations.

🚀Try Time in Status by SaaSJet on the Marketplace