Skip to main content

Last updated: October 17, 2026

StatusPulse — Privacy Policy

This describes exactly what StatusPulse does with your data. It is short because the app does very little. Back to documentation.

The short version

StatusPulse stores no issue data anywhere, and nothing leaves your Atlassian tenant.

The app runs entirely on Atlassian's own infrastructure using Atlassian Forge. It is built to the requirements of Atlassian's Runs on Atlassian programme: an app may use only Atlassian-hosted compute and storage and may not transmit data outside Atlassian. There is no server of ours for your data to travel to, because there is no server of ours.

What the app reads

When you run a report, StatusPulse asks Jira for the issues matching your JQL, using your own permissions. It never sees an issue you could not already open. For each issue it reads:

  • issue key, summary, type, current status, creation date, assignee display name
  • the status-change history (the changelog)

These are read at the moment you press Run report, used to calculate the numbers on screen, and then discarded. They are never written to storage. Close the page and nothing about your issues remains.

What the app stores

One thing: your report settings.

  • Your JQL, the measure (working hours or calendar time), timezone, working week, day start and end, holiday list and SLA targets.
  • Stored in Atlassian's Forge storage, inside your own site's data boundary.
  • Keyed to your Atlassian account, so colleagues on the same site do not see or affect yours.

That is the complete list. No issue content, no summaries, no names, no timestamps from your work.

What the app sends anywhere

Nothing outside Atlassian.

Two things go to Atlassian itself, and only these: once a week, the Atlassian account ids that have saved settings, sent to Atlassian's personal-data reporting service (see “Data retention and deletion”); and, if a calculation fails or your saved settings cannot be read, a generic error line in the app's Forge log, which carries no issue key, summary, name or query.

There are no analytics, no error-reporting service, no third-party scripts, no advertising, no tracking pixels, and no external API calls of any kind. Sending data out would disqualify the app from Runs on Atlassian, and we would rather have the guarantee than the telemetry.

The consequence, stated honestly: we have no idea how you use the app, and we rely on you telling us when something is wrong.

One image, and why it is here

There is exactly one address in this app that is not Atlassian's: the icon shown beside “StatusPulse” in Jira's gadget picker, which is served from shaileshchaudhari.vercel.app/statuspulse/icon-144.png — the same site as this policy.

Atlassian requires a dashboard gadget's icon to be given as an absolute URL, so it cannot be bundled inside the app. When you open the gadget picker, your browser fetches that image the way it fetches any image on the web, which means the server hosting it sees the request. No Jira data, no issue content and nothing identifying you is sent with it, and the app's own code makes no external request of any kind.

We mention a 144-pixel picture in a privacy policy because the alternative is claiming an absolute that is not quite true, and a claim like that is worth less than the thing it was protecting.

Permissions the app requests

  • read:jira-work — to read the issues and status history your query matches. Read-only: StatusPulse cannot create, edit, transition or delete anything in your Jira.
  • storage:app — to save your report settings, as described above.
  • report:personal-data — once a week, to tell Atlassian which account ids have saved settings, so the settings of anyone whose Atlassian account has been closed are deleted. Nothing else is sent.

read:jira-work grants more than StatusPulse uses, and your security reviewer should know that before they find it. It is Jira's broad read permission and covers a large part of the read API. StatusPulse calls exactly two endpoints:

  • POST /rest/api/3/search/jql — the issues your query matches, requesting only the fields listed under “What the app reads”, plus the changelog
  • GET /rest/api/3/status — the list of status names and categories on your site, which is what makes cycle time work without configuration and keeps a renamed status from appearing twice

Both are made as you, with your permissions, so StatusPulse never sees an issue you could not open.

We use the broad scope deliberately. Atlassian's own scope documentation recommends classic scopes over the narrower granular ones, and a scope change after listing — in either direction — is a major version that every site administrator has to approve. Asking once, and telling you exactly what is called, is the honest version of that trade.

If a future version needs a different permission, Atlassian requires a major version upgrade that a site administrator must explicitly approve. Permissions cannot expand silently.

Data retention and deletion

Your settings persist until you change or delete them, or the app is uninstalled.

  • Clear my saved settings on the StatusPulse page deletes yours, immediately, and nobody else's.
  • Closed accounts are cleaned up automatically. Once a week the app reports the account ids that have saved settings to Atlassian's personal-data reporting service and deletes the settings of every account Atlassian reports as closed.
  • Uninstalling StatusPulse removes all of its stored data.

We have no access to the app storage on your site, so we cannot delete one person's saved settings on request; that person can, with the button above, and a site admin removes everyone's by uninstalling the app.

Because no issue data is ever stored, there is nothing else to retain or delete.

Sub-processors

None. The app has no external dependencies at runtime and no third-party services.

Changes to this policy

If this changes materially, the updated date above changes and the change is described in the app's release notes. A change that expands what is collected would also require the permission upgrade described above, which an administrator must approve.

Contact

Questions, or anything that looks wrong: use the support contact on the Marketplace listing, or the StatusPulse support desk.