No — Jira has no native way to build one report across two Atlassian sites, and this is a different question from reporting across two projects. Projects are a boundary inside one site; JQL, dashboards, and the 2026 List view all cross that boundary fine. A site (Atlassian also calls it an instance) is a separate tenant — its own URL, its own users, its own data — and nothing native crosses that one. Neither does a typical Marketplace app, for a specific structural reason: it’s installed into one site and stays there. What does cross it is a user’s own Atlassian login, and that’s the part almost nothing written about “Jira multiple sites” says plainly.
Projects vs. sites: the distinction that gets lost
Search results for “jira report across multiple sites” mostly answer a different question. If your tickets live in project A and project B on the same Atlassian instance, you already have an answer: a JQL filter like project in (A, B) works today, and Jira’s 2026 Summer Release List view adds hierarchy and grouping on top of it (we cover that ground in All my Jira tickets across projects). That’s the cross-project problem, and Jira solved it years ago.
Cross-site is a different wall. A site is yourcompany.atlassian.net — a separate tenant with its own users, its own permission scheme, its own everything. Two companies after an acquisition that never merged tenants. Your company’s Jira and a client’s or vendor’s Jira. A legacy instance nobody migrated. None of Jira’s project-spanning tools — JQL, List view, dashboards — read past the edge of the site you’re logged into, because they were never built to.
What Jira’s own documentation and staff actually say
Ask this directly and the answer is consistent. On the Community forum, someone asked plainly whether two Jira Cloud sites could be linked so issues could be queried together; an Atlassian product manager replied: “This isn’t possible at the moment” (Atlassian Community).
A thread titled “Reporting across two instances of Jira” — 3,540 views — asks it from exactly the angle most people hit it from: one internal Jira and one vendor’s Jira, wanting a combined project report. There’s no native answer in the thread. The suggestions that show up are all third-party: a reporting add-on that connects to “any number of Jira instances,” a workaround piping one instance’s data into another via REST API, and an application link — which one commenter immediately flags as a security tradeoff, since “both sites will be connected and not only your project.”
The same wall shows up from other directions:
- “Could Jira Align be integrated with multiple Jira Applications and sites?” (5,848 views) — Align genuinely can connect to multiple Jira instances, but only because it’s a purpose-built enterprise portfolio tool with a dedicated connector UI for each instance. That’s a heavyweight, admin-configured answer to a question most people just want a report for.
- “Jira Instance - One URL - Possible?” (1,593 views) confirms the same tenant boundary from the infrastructure side: two Jira instances can share a domain, but never a URL — each is its own separate destination, by design.
- “Can Ideas link to tickets in multiple Jira instances?” (1,892 views) got a flat answer from Atlassian staff: Jira Product Discovery “only supports integrated delivery features with a Jira Software on the same instance, not another one within the enterprise umbrella” — and it’s not on the roadmap.
Different products, different years, same ceiling every time: whatever you’re trying to connect across two sites, native Jira stops at the tenant edge.
Why a Marketplace app can’t just fix this either
It’s tempting to assume some app on the Marketplace reads across sites, since apps do so much else. Structurally, they can’t — a Jira Cloud app (Connect or Forge) is installed into one site and runs inside that site’s boundary. The install itself is what scopes it: add a reporting app to Site A and it can only ever see Site A’s data, no matter how good its dashboards are. Add the same app to Site B separately and you have two independent installs producing two independent reports — combining them is still your job, by hand or by export, which is exactly the workaround pattern the “Reporting across two instances” thread landed on.
What actually reaches across sites: your own login
The one thing that isn’t scoped to a single site is the person. Atlassian’s OAuth 2.0 (3LO) flow — the standard way a third-party app signs a user in with their real Atlassian account — issues a token good for every site that person has access to, and the accessible-resources endpoint returns that whole list, not one site chosen at setup (Atlassian Developer docs). A tool built on that flow inherits your reach: sign in once, and it can read every site your account touches in the same session — no second install, no per-site connector to configure.
That’s the structural difference between a Marketplace app and a tool built around your own account: the app is bound to a site at install time; you are not bound to any site at all.
The fix, plainly
OneView is built on that account-level access. You sign in once with your real Atlassian login, it pulls in every connected site, and you group, roll up, and add your own columns across all of them in one grid — the same reach that made “reporting across two instances of Jira” a recurring, unanswered Community question for years. Start a free trial and point it at your own two (or more) sites.
If your actual gap is projects, not sites, that’s solved territory — see All my Jira tickets across projects for what JQL and the 2026 List view already do natively. And if some of the work you’re rolling up isn’t in Jira at all, the same site-vs-tool boundary shows up on Microsoft’s side too: see Planner tasks by assignee across plans and a Planner dashboard across all plans for the Planner version of the same underlying problem. And if the gap you actually hit isn’t sites at all but numbers that don’t add up, see summing story points from children to a parent. And if it’s neither — you’re on one site and just want sprint progress rolled up across your projects — see a Jira dashboard across multiple projects.