Skip to main content

Last updated: October 17, 2026

StatusPulse

StatusPulse tells you how long work actually sat in each Jira status, measured against your working calendar rather than raw elapsed time.

Privacy Policy•Terms of Service•Customer Support

The one idea

Jira knows when an issue changed status. It does not tell you how long it sat anywhere. Most tools answer that by subtracting two timestamps, which counts nights, weekends and public holidays as working time. A ticket raised on Friday afternoon and picked up on Monday morning did not take three days of anybody's attention.

StatusPulse measures the hours your team was actually working.

Running your first report

  1. Open Apps → StatusPulse in Jira.
  2. Put a JQL query in the box. If you are not sure, start with project = ENG AND created >= -30d.
  3. Choose Working hours (the default) or Calendar time if your team genuinely runs 24/7.
  4. Set your timezone, working week, day start and end.
  5. Press Run report.

You get two tables.

Where the time goes — median and 85th percentile working time per status, across every issue in your query. This is the one to look at first: the top row is where your process actually spends its time.

By issue — one row per issue, showing its current status, how long it has been sitting there since it last arrived, and which status consumed the most of its life. Those are different numbers on an issue that came back from review, and the column means the second one.

The settings

  • Measure — Working hours excludes nights, weekends and holidays. Calendar time counts every millisecond.
  • Timezone — the zone your working day is defined in, chosen from a list of nine common zones (including Asia/Kolkata, UTC, Europe/London and America/New_York). Daylight saving is handled: a spring-forward day really is an hour shorter.
  • Working week — Saturday/Sunday, Friday/Saturday, Sunday only, or all seven days.
  • Day starts / ends — 24-hour time, e.g. 09:00 and 17:00.
  • Holidays — comma-separated dates, e.g. 2026-01-26, 2026-08-15, 2026-10-02. Each one is excluded entirely.
  • Targets — optional SLA targets, e.g. In Review: 8h, Blocked: 2d, checked against working time. With Working hours, d is one of your working days and w one working week — 2d on a 09:00–17:00 day is 16 hours, not 48 — and every d in the report means the same. With Calendar time, d is 24 hours.

Save these settings stores them against your Atlassian account, not the site. Two people on the same Jira can measure against different hours, which matters for distributed teams. Clear my saved settings deletes yours; the page keeps what is on screen until you reload it.

The dashboard gadget

Add StatusPulse — time in status to any Jira dashboard. It shows median working time per status for whatever you last saved on the StatusPulse page, using the same calendar.

It has no settings of its own, on purpose. A second place to configure the same thing is a second place for the two to disagree. Change the query on the page and the gadget follows.

One consequence, stated plainly: settings are saved per Atlassian account, so on a dashboard several people look at, each person's gadget shows their own saved query and working calendar. If your team needs one agreed number on a shared dashboard, agree the query and have everyone save the same one — or tell us, and a shared gadget configuration becomes a considered feature rather than a default nobody asked for.

Exporting

Press Show CSV after a report. The export is one row per issue per status, which is the shape a pivot table wants. Hours are decimal, so they add up. A column-per-status layout was deliberately avoided: status names differ between projects, so that sheet goes ragged the moment your JQL spans two of them.

Reading the numbers honestly

  • Median, not average. Cycle-time distributions have long tails. One ticket stuck across a shutdown drags an average somewhere no team recognises. The 85th percentile column is the number to quote for a realistic worst case.
  • “Partial history” badge. Jira caps how much changelog it returns with a search, and it returns the most recent entries — so on a very long-lived issue it is the early life that is missing. StatusPulse measures those issues from the oldest entry Jira actually sent and counts the unknown period against no status at all. Their totals are a lower bound, and the row is flagged rather than hidden.
  • Re-entry counts. An issue that entered In Review four times is telling you something the total alone does not.
  • A renamed status is still one row. StatusPulse matches on the status identifiers Jira sends alongside the names, so a status renamed from QA to Testing appears once, under the name it has today. If StatusPulse cannot read your site's status list it says so, and in that case a renamed status may appear twice.

Limits

  • A report covers up to 200 issues. Narrow the JQL for a complete picture of a larger set; a report that quietly truncates is worse than one that says so.
  • StatusPulse reads Jira issue data only. Nothing leaves your Atlassian tenant — see the privacy policy for exactly what is read, stored and sent.
  • It is not a time-tracking tool. It measures how long work sat in a status, not how long a person spent on it. If you need to know who worked how many hours, you want a worklog app.

Troubleshooting

A blank page, or a loading placeholder that never finishes

Almost always a DNS or network problem on your side, not the app. Every Forge app loads its interface from *.cdn.prod.atlassian-dev.net. If your network cannot resolve or reach that domain, Jira draws the frame and then waits for an app that never loads, with no error message. Confirm it by running nslookup probe.cdn.prod.atlassian-dev.net: if that returns nothing or NXDOMAIN, that is your answer.

  • Router or ISP DNS. Point the machine at a public resolver such as 8.8.8.8 and 1.1.1.1, then flush the DNS cache.
  • Corporate firewall or proxy. Ask IT to allow *.cdn.prod.atlassian-dev.net, which Atlassian documents as required for Forge apps.
  • A browser extension. Ad blockers sometimes block third-party frames. Pause them for your Jira site and reload.
  • DNS filtering such as a Pi-hole, NextDNS or OpenDNS with an aggressive blocklist.

“Jira rejected the search”

The JQL is not valid, or you cannot see the projects it names. Try the same query in Jira's own issue search first.

“Showing the first 200 issues”

Narrow the query by project, date range or issue type. Two accurate reports beat one truncated one.

The numbers look too small or too big

Check the Measure setting and your holidays list: on Working hours a Friday-evening-to-Monday ticket shows a few hours, not three days. Then check the working day and week: a day of 00:00–23:59 counts everything.

The gadget shows different numbers from the page

For one person it should not: the page's settings were changed and not saved. Press Save these settings and reload the dashboard. Two people on the same dashboard can see different numbers by design, because each runs their own saved settings.

The StatusPulse icon is missing from the gadget picker

The icon is served from shaileshchaudhari.vercel.app/statuspulse/icon-144.png. If your network blocks that address the gadget still works — only its picture is missing.

Reporting a problem

Send the JQL, the settings you used, and roughly what you expected. If you can include an issue key where the number looks wrong, that is the fastest possible bug report: the calculation is deterministic, so one example usually reproduces it exactly. Email shailesh93602@gmail.com or use the StatusPulse support desk.