Can JQL search across two Jira sites? The 2026 answer
Short version: no, and Atlassian’s own request for it has sat open since 2022. Here are the four things that do work — including the trade-offs the vendor pages leave out. Last reviewed August 2026.
Why JQL stops at the site boundary
A JQL query runs against the search index of the one Jira site it was issued on. Each Jira Cloud site is a separate tenant with its own index, its own custom-field IDs, its own workflows, and its own user directory — so there is no syntax that reaches sideways into another site. You cannot reference another site’s project key in a query, there is no federated search endpoint, and no permission grant unlocks it. This is architecture, not configuration.
The same boundary explains the follow-on questions people usually ask in the same breath: boards, sprint reports, and the dashboard gadgets that depend on JQL are all single-site for exactly the same reason. Atlassian staff have confirmed this directly in community threads about multi-site setups.
Is Atlassian going to fix it?
Not on a timeline you can plan around. The public request JRACLOUD-79909 — “JQL search across multiple instances” was opened in October 2022 and is still marked Gathering Interest, the earliest stage of Atlassian’s pipeline, with no fix version attached. Its Server/Data Center sibling, JRASERVER-72751, is likewise unresolved.
Read that as the honest signal it is: years of votes and comments have not moved it out of the intake stage. Design for the boundary.
The four things that actually work
1. Consolidate the two sites into one
If it is genuinely possible, this beats every other option permanently — one index, one set of boards, JQL that just works. It is also the option people skip past too quickly. Consolidation is realistic when the split is historical (a past acquisition, a team that spun up its own site) and unrealistic when the split is structural: separate legal entities, contractual data separation, a client who will never work in your site, or a regulator who requires the boundary. Be honest about which you are in before buying anything.
2. Aggregate for display only
Several dashboard and reporting apps can pull data from multiple sites and render it side by side. This is useful for a management overview and genuinely cheap. What it is not is a cross-site query: you cannot filter the combined set, sort it, run a sprint report on it, or feed it into automation. If your requirement is “one screen that shows both”, this is the shortest path. If your requirement is “search and act across both”, it will disappoint you.
3. Query both sites yourself via the REST API
Two API calls, one per site, merged in your own code — a script, a scheduled job, or a small internal dashboard. Free, completely flexible, and the right answer for reporting and one-off audits. The costs are real and recurring: you own authentication for both sites (including rotating OAuth tokens), you own the field mapping between two schemas that will drift apart over time, and you own pagination and rate-limit handling. It is a fine weekend project and an annoying thing to maintain for three years.
4. Mirror the issues so each site has a local copy
This is the only option that makes native JQL, boards, and reports behave — because the search index can only find issues that exist locally. A sync tool creates and maintains a real issue on each side, keeping fields, status, comments, and attachments aligned, so each team queries their own Jira normally and sees the shared work in the results.
The trade-off, stated plainly: a mirror is a copy. You inherit sync lag, conflict resolution when both sides edit the same field, and a moving part that can break. You are trading a hard architectural limit for an operational one. That is usually a good trade when two organisations must each keep their own Jira — and a bad one if you could simply consolidate.
Tools in this space include Exalate (scriptable, handles Data Center and non-Jira systems, from $100/mo per integration), Unito (many tools beyond Jira), Backbone Work Sync, and our own Ticketize.it (Jira Cloud ↔ Jira Cloud only, flat $0–29/mo). We build one of these, so weigh that accordingly — the 2026 price breakdown lists what each actually costs, including a competitor’s free option.
Choosing between them
A rough decision order that holds up in practice. Can you consolidate? Do that. Do you only need to look? Aggregate for display. Do you need a report, once or monthly? Write the API script. Do two teams need to work the same items in their own Jira, every day? Mirror them — nothing else makes the native tooling work.
What guest access does and does not solve
Atlassian shipped free guest access in April 2026 (five guests per paid seat), and it is genuinely useful: an external collaborator can work inside one space on your site without a licence. It does not join two sites together. A guest is a person you let into your Jira — they still cannot run a query that spans both, and it does nothing for a partner who insists on staying in their own instance. Different problem, worth knowing about, not a substitute.
Can JQL search issues across two Jira Cloud sites?
No. A JQL query runs against the index of the single Jira site it was issued on. There is no cross-site JQL syntax, no federated search, and no way to reference another site's project key in a query. This is an architectural boundary, not a permissions setting — each Jira Cloud site is a separate tenant with its own index.
Will Atlassian add cross-site JQL search?
Not soon. The public feature request JRACLOUD-79909 (“JQL search across multiple instances”) has been open since October 2022 and is still at “Gathering Interest” — the earliest stage in Atlassian's pipeline — with the Server/Data Center equivalent JRASERVER-72751 similarly unresolved. Neither has a target release. Plan around the boundary rather than waiting for it to disappear.
Do boards, dashboards and reports work across sites?
Boards and reports do not — they are confined to a single site, which Atlassian has confirmed directly in community threads. Some dashboard gadgets and third-party apps can display data pulled from several sites side by side, but that is aggregated display, not a real cross-site query: you cannot filter, sort, or run a sprint report across the combined set.
What actually makes cross-site search work?
Only one thing makes native JQL, boards, and reports behave: the issue has to exist locally on the site you are searching from. That means either consolidating both sites into one, or mirroring the issues you care about into each site with a sync tool so each Jira has a real local issue to index.
Does Atlassian's free guest access solve this?
No. Guest access (shipped April 2026, five guests per paid seat) lets an external person work inside one space on your site. It does not join two sites together, and a guest still cannot run a query spanning both. It solves “let someone in” — not “search across two Jiras”.
Make both Jiras searchable from either side
Ticketize mirrors issues between two Jira Cloud sites so each team’s own JQL, boards, and reports include the shared work. Free tier, no credit card.
No credit card required · Free tier included · Set up in minutes