Your team tracks development in one Jira instance, another business unit has its own, and an external delivery partner works in a third. Each team has its projects, workflows, and responsibilities, so this arrangement can work well for daily execution. The difficulty appears when a delivery manager needs to report on work that spans all three environments.
Questions that seem straightforward become harder to answer. Which high-priority items spent the longest waiting for review? Are testing delays concentrated in one team or appearing across several? Each Jira site contains part of the answer, but someone needs to collect that data and make it usable before the delivery meeting.
The reporting work nobody planned for
The usual workaround is to ask each team for a report, export the results, and combine them in a spreadsheet. For an occasional update, that may be enough. When the report becomes a weekly responsibility, however, the preparation becomes a recurring task of its own.
One team sends its data on Thursday and another on Friday. Their filters cover slightly different work, or a changed column means the spreadsheet needs adjusting. Before the project manager can examine the results, they have to check that the inputs belong together. Even with a reliable template, someone still owns collecting, checking, and updating the data.
The limitations become more obvious during the meeting. A stakeholder asks to see high-priority bugs only, or wants to know which work items account for a long review time. Someone else asks whether the same pattern appears in another region. If the prepared summary does not contain that detail, the project manager has to open separate reports or take the question away for a follow-up.
That delay matters because the people who can explain the work and agree on an action are already in the room. A useful discussion can end with another request for data, leaving the decision until the next update.
A shared delivery problem can disappear inside separate reports
Consider a hypothetical organization with three delivery teams. Each team has a few work items that spent several days awaiting approval. In separate reports, those items might look like occasional local delays. Bringing them together gives the delivery manager a reason to investigate whether the teams share an approval dependency.
Perhaps they are waiting for the same specialist or working with unclear approval criteria. The delays might also have unrelated causes. A combined view makes it easier to identify the affected work items and take those questions to the relevant teams.
The underlying detail matters just as much as the overall pattern. A high average review time could reflect a widespread queue, or it could be driven by a handful of unusually complex requests. Those situations call for different responses. To decide where to focus, a delivery manager needs to move from the summary to the work items behind it without starting another round of report preparation.
Why another Jira dashboard may not solve it
Creating a dashboard covering all the sites seems like a natural next step. However, Atlassian’s documentation states that built-in Jira gadgets cannot display data across multiple Jira instances. For that requirement, Atlassian points users toward Marketplace apps.
Searching for a solution can also lead to a different problem. Terms such as “sync Jira instances” or “sync two Jira instances” commonly describe keeping corresponding work items updated between environments. If your goal is a combined workflow report, you may only need selected data from each site available for analysis. Synchronizing changes between work items is a separate requirement.
Bring multiple Jira instances into a Time in Status report
Multi-site reports in Time in Status Advanced Edition addresses this reporting need by bringing workflow data from connected Jira Cloud sites into a combined report inside Jira. You can examine the selected work together without first assembling separate exports.
Each work item retains its source through the Site and Connections fields. Keep these visible as columns, use them to group rows, or examine the selected work across sites. Filters, sorting, aggregations, and Pivot Mode let you adjust the view as the reporting question changes.
For a delivery manager, this makes the follow-up question easier to handle. Starting with the combined report, you can filter to a relevant priority or work type where those fields are shared, sort by time in review, and inspect the work items with the longest durations. Grouping by site then helps you see where those items belong.
Examine work across connected Jira sites while keeping the source of each work item visible.
Three questions to explore in your first multi-site report
1. Which work items spent the longest in review?
Use Time in Status to examine time accumulated in the relevant review statuses. This gives you a specific set of work items to discuss with the teams involved, rather than asking everyone for another general progress update.
For example, a report may show that several high-priority items across two sites spent much longer in review than the surrounding work. Those items become the starting point for checking whether a shared dependency, additional checks, or another factor contributed to the delay. Time in a status helps locate the delay; it does not establish its cause or prove that someone was actively working on the item throughout that period.
2. Where does work repeatedly return to testing?
Use Status Count to examine repeated entries into testing and Transition Count to inspect particular workflow movements. Together, these views help you distinguish work that passed through a stage several times from work that repeatedly followed a specific return path.
The distinction matters when deciding what to investigate. Multiple testing entries might reflect planned validation rounds, while repeated transitions from testing back to development may warrant a discussion about rework. Inspecting the affected work items gives that discussion a concrete basis without assuming every repeated movement means the same thing.
3. When did work enter an approval stage?
Use Status Entrance Date to examine when work items entered relevant statuses across the selected sites. This adds timing context to the durations and counts you are reviewing.
For example, if several items entered approval around the same period, you have a focused set of records to examine with the team. Their dates and workflow histories can help you reconstruct what happened and identify what additional context you need.
How to connect two Jira instances for reporting
Start on the site that will share data. Define the work items through JQL, choose the work schedule used for duration calculations, and select the Jira fields to make available. Generate a connection token, then use it on the receiving site to establish the connection.
On the receiving site, open Multi-site reports and configure the report. Choose the connected sites, report type, and fields, then apply the configuration and set the reporting period. You can also include work items from the current site.
Each sharing site defines the work items, fields, and work schedule it contributes.
For the first report, choose a scope you already understand: two sites, a relevant set of work items, and one delivery question. A familiar reporting task makes it easier to check the results and assess whether the combined view helps you answer questions that previously required manual preparation.
Make cross-site comparisons meaningful
Jira multi-site reporting brings the data together, but the measurements still need a shared interpretation. Before comparing results, check the scope, workflow definitions, and calendars behind them.
Check | What to establish |
|---|
Reporting scope | The period and selected work items fit the question you are investigating. |
Work types and volume | You understand the categories and number of work items behind each result. |
Status meaning | The stages being compared represent comparable activities. |
Work schedules | You understand differences in working hours, weekends, and other exclusions. |
The report matches statuses by exact name. “Review” and “In Review” remain separate, although you can deliberately combine relevant stages using a status group. Check their meaning first: identical names can describe different activities, just as different names can describe a similar phase.
Duration values retain the sharing site’s work schedule. A business-hours calculation and a 24/7 calculation measure time differently, so account for those settings when interpreting the results. Also check that all selected connections loaded. If you continue with a partial report, the excluded sources matter when discussing totals or comparisons.
Replace one recurring report first
The best place to evaluate the feature is the reporting task you already repeat. Take the spreadsheet you prepare for a delivery review and identify the sites, work items, fields, and workflow measurements it needs. Build that view in Multi-site reports, then save the configuration.
Saved reports preserve the relevant report settings and table layout. You can define viewer and editor access for colleagues, reopen the agreed configuration, and rerun it for the next review.
Reuse the reporting configuration for recurring delivery reviews.
Test the report against the questions your stakeholders actually ask. Can you find the longest review durations across the selected sites? Can you inspect the work items behind a summary? Can you narrow the view during the discussion and leave the meeting with a decision?
For your first evaluation of Time in Status Advanced Edition, bring one real reporting task from two Jira sites. Build the combined view, save it, and use it in your next delivery review. You will have a practical basis for deciding whether it can replace the manual preparation your team does today.
Multi-site reports documentation
