Skip to content

Dwell

Jira time in status, with your data never leaving your tenant

Flow metrics require reading every issue's full change history — assignees, comments, the lot. Where that reading happens decides whether adding a reporting app means adding a data processor. Dwell does it inside your own Atlassian cloud.

What is “no data egress”? It means the app never sends your Jira issue data to any server outside Atlassian's cloud. Dwell runs entirely inside your Atlassian tenant — it is a Forge app carrying Atlassian's Runs on Atlassian badge — so your issue history, assignees and comments never leave. It inherits Atlassian's SOC 2 / ISO 27001 and data residency because the processing happens on Atlassian's own infrastructure.

Teams in regulated industries choose no-egress apps for a structural reason: a vendor breach cannot expose project data the vendor never held.

Why hosting matters more for flow metrics than for most apps

A time-in-status report is not computed from a summary. To know how long an issue sat in Code Review, something has to replay that issue's changelog — every transition, with timestamps and the account that made it. To do it across a project, that replay runs over thousands of issues.

Does a time-in-status app see my issue data?

Yes. Any app that reports on status durations reads your issues, and reading is not the question worth asking — the question is where the reading happens, and whether a copy is kept somewhere you do not control.

There are two shapes on Atlassian Cloud. An app can run on the vendor's own servers, pulling your data across the internet and usually caching it there so reports are fast. Or it can run on Atlassian's infrastructure, where the compute and the storage both sit inside the same cloud your Jira is already in. Both shapes ship good products. Only the second one leaves your procurement paperwork unchanged.

How Dwell runs on Atlassian

Dwell is built on Forge, Atlassian's app platform, and it declares no external permissions at all. Its resolvers execute in Atlassian's runtime; the index it builds from your changelog is stored in Atlassian-hosted storage, pinned to your site's data residency region. There is no Hullara server in the path, because there is no Hullara server.

Practically, this means three things for a security review. There is no new data processor to contract with, because no data reaches Hullara. There is no vendor-side breach surface holding your issue history. And the certifications that apply are Atlassian's own, since Atlassian's infrastructure is doing the work.

What it does not mean. Runs on Atlassian is not a compliance certificate for your organisation, and Hullara does not claim your deployment becomes SOC 2 compliant by installing an app. It means the processing stays inside a boundary you have already assessed.

What you get, without a trade-off for it

In-tenant apps used to mean fewer features. That constraint has largely gone: Dwell computes the same flow metrics you would expect from a hosted reporting tool.

  • Per-issue panel — time in each status plus lead time, on every issue. Free on every issue, at any team size.
  • Median and p85, not just averages — because the average cycle time hides the tail that actually hurts.
  • Aging work in progress — the open issues already past your p85, flagged before they stall.
  • Cycle-time trend by week, so you can see whether flow is improving rather than guessing.
  • Cycle-time histogram and a dashboard gadget.
  • Group by assignee, type, priority or status; export any report to CSV.
  • Reports resolve as the viewing user, so issue-level security is respected — people only see issues they are already allowed to see.

Full detail of every surface is in the Dwell user guide, and what is stored is set out in the privacy policy.

How to check any Jira app's hosting model yourself

Do not take a vendor's word for this — including ours. It is visible on the Marketplace, and it takes under a minute per app.

  • Open the app's Marketplace listing and look for the Runs on Atlassian badge near the top. Present means in-tenant; absent means it is not making that claim.
  • Check the listing's Data residency and security sections, which state where data is stored and processed.
  • Browse Atlassian's own Runs on Atlassian collection, which lists apps that qualify.

Runs on Atlassian vs Connect — what is the difference?

Runs on Atlassian describes a Forge app that stores and processes data only on Atlassian's infrastructure, with no external egress. Connect is the older model, where the app is a service the vendor hosts and Atlassian calls out to it — so the data travels to the vendor. Many good apps are Connect apps, and plenty of Forge apps deliberately open egress to integrate with something outside Atlassian. The badge is not a quality judgement; it is a statement about where your data goes.

Being fair about it: several established time-in-status apps carry the badge too, and some of them carry Cloud Fortified, which Hullara does not yet. If a vendor's operational maturity programme is what your procurement asks for, weigh that honestly — see the Timepiece comparison and the SaaSJet comparison, which say where each of them is the better pick.

Questions

New to this measurement entirely? Start with how to see time in status in Jira.

Questions

Does Dwell send my Jira data to an external server?
No. Dwell Runs on Atlassian — there is no egress, and no Hullara-operated server in the path. Your issue data stays in your tenant.
Is Dwell SOC 2 compliant?
Dwell runs on Atlassian's infrastructure and inherits Atlassian's SOC 2 / ISO 27001 for the processing it does there. Hullara itself does not hold a separate SOC 2 report, and nothing is processed off-platform.
Can I get time in status without signing a data-processing agreement with a new vendor?
With a Runs-on-Atlassian app there is no external data processor to contract with, because your data never leaves Atlassian. Your existing agreement with Atlassian already covers where it sits.
Where is the data stored, and does data residency apply?
In Forge's Atlassian-hosted storage. Apps that use only Forge storage follow your site's data residency setting, so a site pinned to a region keeps the app's index in that region too.
What does Dwell store about people?
Its index stores the Atlassian account ID of an issue's assignee, so reports can be grouped by person. Display names are read from Jira live when you use the assignee filter and are not kept. The full detail is in the [privacy policy](./privacy-dwell.html).