You can share a Jira status report without a login, but the two usual ways each have a real cost: a public dashboard is “visible and searchable on the internet” per Atlassian’s own docs, and a PDF export is stale the second you send it. The login-free option that’s also scoped is to deliver a live report into a tool the reader already has, so it stays current without publishing your Jira data to the open web.
How do you show someone a Jira status if they don’t have a login?
There are three honest answers, and people usually only think of the first two. You can make a Jira dashboard public so anyone can open it in a browser. You can export the issues to a PDF or Excel file and send it. Or you can deliver a live report into a tool the person already uses. All three skip the Jira login. Only one of them is both login-free and scoped to the person you actually want to see it, and it’s the one people forget.
Is a public Jira dashboard actually safe to share?
Not the way most people assume. A public dashboard does solve the login problem, but Atlassian is explicit about what “public” means. Their documentation states: “Public sharing means sharing the dashboard with users who are not logged in to your Jira Cloud site. Note that if you share a dashboard publicly, it will be visible and searchable on the internet” (Atlassian Support). That’s the whole problem in one sentence. “Login-free for my client” and “indexable by Google for everyone” are the same setting. There’s no per-recipient scope — you can’t make a dashboard public to just one person.
It’s also gated and sticky. Public sharing is an all-or-nothing site-level switch a Jira admin has to turn on before anyone can use it, and Free Jira sites can’t be opened to the public at all. Turning the switch back off “prevents new and not-yet-shared dashboards and filters from being shared. It does not restrict any filters or dashboards that have already been shared” — so anything already exposed stays exposed until someone changes it by hand. Atlassian even ships an admin page just to audit which filters and dashboards are shared publicly, because in a real org it’s easy to lose track of what got made public. If you need an audit tool to find your accidental leaks, the mechanism is doing you a disservice.
Why not just export a PDF?
Because it’s dead on arrival. An export is genuinely login-free — you attach a PDF or an Excel file to an email and the reader opens it with no Jira account. But the file is a snapshot frozen at export time. The moment a ticket moves, a status flips, or a new issue lands, the report is wrong, and nobody re-opens last Tuesday’s PDF to check. So you’re back to re-exporting and re-sending on every cadence, by hand, forever. A file answers “what was the status when you sent this,” never “what’s the status right now.” For a weekly stakeholder update that’s a standing chore; for an exec who checks whenever they feel like it, it’s usually stale by the time they look.
What’s the login-free option that’s also scoped?
Deliver a live report into a tool the reader already has, addressed to them specifically. This is the route that clears both bars at once: no login for the reader, and no public URL sitting on the open web. Instead of publishing your Jira data to everyone or freezing it into a file, you write a current issue table into a place only your reader opens — their own notebook. It stays fresh because it’s connected to the filter, and it stays private because it was shared to one destination, not indexed by the internet.
| Public dashboard | PDF / Excel export | Delivered live report | |
|---|---|---|---|
| Reader needs a Jira login | No | No | No |
| Visible to the whole internet | Yes — “visible and searchable” | No | No |
| Scoped to one recipient | No — public or nothing | Yes (whoever you email) | Yes (their notebook) |
| Stays current | Yes | No — stale at export | Yes — refreshes on a schedule |
| Manual work each cycle | None, but always public | Re-export + re-send | None |
The pattern lines up cleanly. The public dashboard trades scope for freshness; the export trades freshness for scope; only the delivered report keeps both.
Is this a real thing people ask for?
Yes, in plain words. On the Atlassian Community, a user described wanting to “export a list of our open and in progress Jira issues into a table or list in OneNote on a weekly basis for team meeting discussions,” with the issues hyperlinked (Atlassian Community thread). Nobody in that thread wanted a public URL on the internet, and nobody wanted to re-export a PDF every week. They wanted the current Jira data to show up in the tool they already had open for the meeting. That’s the same request as “a status report without a login” — just stated from the reader’s side.
The honest pitch
OneNote Reports for Jira is built for the third column. Point it at a saved Jira filter and it writes a live, clickable issue table into a specific OneNote page, then refreshes it on the schedule you set. The reader opens their own notebook and sees the current status — no Jira login, no public dashboard “visible and searchable on the internet,” and no PDF that went stale on Tuesday. It’s the login-free report that’s also scoped: shared to their notebook only, and always up to date. See it at onenote.crosstowntech.com.