In many teams, performance is measured by the number of closed issues. However, relying solely on general statistics is not enough to gain a clear understanding of how the workflow is actually performing. Jira status report allows you to dig deeper into your processes, identify bottlenecks, and uncover opportunities for improvement by showing how issues progress through different statuses.
In this guide, you’ll learn what Jira status reports are, what the native reporting capabilities can and cannot do, and how Time in Status by SaaSJet can help you go beyond standard reports with advanced, time-based status insights.
What is a Jira status report?
A Jira status report summarizes the current and historical statuses of issues within a project. It transforms raw data into a clear picture of the workflow by showing the ratio of completed to open issues, highlighting bottlenecks, and revealing how long issues spend at each stage of the process.
Depending on your goals, such a report can include information on the current status of issues, the number of issues at each stage, processing time, transition history, the frequency of status changes, and overall trends and bottlenecks affecting projects and sprints.
There are two things people usually mean by “status report,” and a good one covers both:
- A progress snapshot — the current state of work by status, priority, assignee, or issue type. This helps managers and stakeholders answer the question: “Are we moving in the right direction?”
- Workflow analytics — insights into how much time issues spend in each status, where bottlenecks occur, and how cycle time and lead time evolve over time. This information helps team leads and Scrum Masters optimize their processes.
Jira’s native functionality does a good job of providing progress snapshots and visualizing workflows at the board level. However, obtaining detailed execution data for individual issues — such as how long each issue remained in a specific status or how often it moved backward in the workflow — is exactly where many teams face challenges.
Why Jira status reports matter
Without proper reporting, teams evaluate project health on assumptions — a task marked “In Progress” may have sat idle for two weeks, and no one notices until the deadline slips. Status reporting replaces that guesswork with data, which pays off in three ways:
- Better forecasting — historical status data makes sprint planning and delivery estimates far more reliable than gut feel.
- Real transparency — stakeholders get an objective, up-to-date view of progress instead of fragmented verbal updates.
- Faster decisions — when the data shows where work actually stands, teams act on facts instead of debating impressions.
(What to look at to catch the problems behind those slipped deadlines is the next section.)
What information should a Jira status report include?
The right contents depend on your objective, but these metrics consistently add value:
| Metric | What it tells you | Watch for |
|---|---|---|
| Current issue status | How work is spread across stages | One stage holding most of the issues |
| Time spent in statuses | How long work sits at each stage | A single stage far above all the others |
| Status transition history | The real path work takes through the process | Frequent backward moves |
| Transition counts | How often issues enter a given status | Repeated re-entries into the same status |
| Aging issues | Which items are stuck unresolved | Old items with no recent movement |
| Assignee insights | How workload is split by person | One person carrying a disproportionate load |
Each of those red flags maps to a specific report later in this guide.
Time in Status report — duration per issue, per status.
Types of Jira status reports
Before building anything, decide which report answers your question.
| Report type | Answers the question | Best for |
|---|---|---|
| Status snapshot | What’s the current breakdown by status? | Stakeholder updates, standups |
| Progress over time | Are we closing work faster than it arrives? | Release and sprint tracking |
| Time in status | How long does work sit in each stage? | Finding bottlenecks |
| Sprint status | Did we deliver what we committed to? | Sprint reviews, retrospectives |
| Status/transition count | How often does work bounce between stages? | Spotting rework and churn |
A complete status report often pairs a snapshot for stakeholders with a time-in-status view for the team. Below, we’ll create both.
Who uses Jira status reports
| Role | What they get from it |
|---|---|
| Project managers | Visibility into progress and early warning of delivery risks; more realistic timelines. |
| Scrum Masters | Bottlenecks that slow sprint execution, surfaced as objective talking points for retrospectives. |
| Engineering managers | Delivery-health trends across projects and data to back resource and process decisions. |
| Jira administrators | A faster, consistent way to answer reporting requests from multiple departments. |
How to do a status report in Jira (native methods)
You can get a usable status report with four native routes, from the simplest snapshot to the closest-to-flow:
1. Jira dashboards and gadgets
The fastest option. Build a dashboard from gadgets pointed at a project or saved filter.
- Go to Dashboards → Create dashboard.
- Add gadgets — Pie Chart, Created vs. Resolved, Two-Dimensional Filter Statistics, Filter Results — and set each one’s data source.
- Configure the statistic type (e.g., group the Pie Chart by Status).
- Share the dashboard or display it on a wall monitor.
Good for: a live, at-a-glance view. Limitation: gadgets show current counts, not how long issues stayed in each status.
2. Built-in agile reports (Control Chart & Cumulative Flow Diagram)
This is Jira’s closest native attempt at flow analytics, found under your Scrum or Kanban board’s Reports menu.
- Control Chart plots cycle time and lead time for completed issues, with a rolling average — useful for a high-level sense of how long work takes between two columns on that board.
- Cumulative Flow Diagram (CFD) shows the number of issues in each status over time. Widening bands reveal where work is piling up, making it a quick visual bottleneck check.
- Created vs. Resolved gives you a sense of throughput of whether you’re closing work faster than it arrives.
Good for: a board-level read on cycle time and where WIP accumulates. Limitation: these are scoped to a single board, measure time between board columns rather than every workflow status, and don’t give you an exact, per-issue, per-status duration table you can export or break down by assignee, sprint, or epic.
3. Confluence Jira report template
If your team works in Confluence, the built-in Jira report template pulls Jira data into a shareable page. The Status Report option shows project and fix-version progress in dynamic pie charts by status, priority, component, and work type via the Jira Chart macro, updating automatically as issues change.
- In Confluence, click Create, then open the Templates panel and search for Jira.
- Select the Jira report template, then choose Status Report.
- Point it at your project and fix version (or switch to Advanced mode and paste JQL).
Good for: narrative updates that combine charts with written commentary. Limitation: reports current state, not duration.
4. JQL filters and export
For ad-hoc reporting, build a JQL filter, then export the issue list to Excel or Google Sheets for manual charting.
project = "ABC" AND status WAS "In Progress" AFTER startOfWeek() ORDER BY updated DESCJQL is strong for filtering and finding issues — including historical clauses like status WAS and status CHANGED. But it has a hard limit worth knowing before you invest time in it.
The limitation that matters: native Jira can’t quantify time in status across issues
Here’s the gap that affects almost every team. Native JQL can identify that a status changed and when a transition happened, but it cannot calculate the exact time an issue spent in each status. The Control Chart gives you a board-level cycle-time average, and the CFD shows the shape of your flow, but neither produces a precise, exportable breakdown of duration per status across many issues.
In practice: native Jira can tell you a ticket is “In Progress” and that it entered that status five days ago, and it can chart your board’s average cycle time — but it can’t easily tell you that your average bug spends days in QA while sitting only hours in development. That single number is the most useful one for finding bottlenecks. Related gaps:
- No per-status duration table — cycle/lead time is board-scoped and column-based, not a status-by-status report across issues.
- No cross-issue transition report — there’s no built-in way to analyze transitions between specific statuses across many issues at once.
- No repeated-status count — finding how many times issues returned to “Open” is impractical with standard reports.
- No non-working-hours adjustment — native flow reports count weekends and nights, inflating durations.
- Manual effort — stakeholder-ready reports usually mean stitching together gadgets, filters, and spreadsheets.
To close these gaps, you need a dedicated reporting app.
How to create an advanced Jira status report with Time in Status by SaaSJet
Time in Status by SaaSJet reads your workflow change history and builds time-based status reports automatically — no JQL gymnastics, no manual spreadsheets.
It generates seven report types out of the box:
- Time in Status — how long each issue stayed in every status, plus a total.
- Assignee Time — time per assignee (with user groups for teams).
- Average Time — averages across a set of issues, by day, week, month, or quarter.
- Status Count — how many times an issue entered each status (rework signal).
- Transition Count — how often work moved from one status to another.
- Status Entrance Date — when an issue first entered a given status.
- Time in Status per Date — time in a status within a chosen reporting window.
These cover the questions native Jira can’t answer cleanly: how long work spends in each stage (Time in Status / Average Time), exactly when it moved (Status Entrance Date), how it travels between stages (Transition Count), and which issues keep cycling through the same status (Status Count).
To create a report:
- In Jira, open Apps → Time in Status by SaaSJet.
- Pick a Report type and select issues by project, filter, sprint, assignee, or JQL.
- Set a working calendar (not “default”) so weekends, breaks, and holidays are excluded — this is what makes the durations trustworthy.
- Use Status Groups to merge statuses into logical stages (e.g., combine “In Review” and “Code Review” into one “Review” column).
- Switch between Table, Chart (Pie / Bar / Area), and Pivot views.
Average Time report — time per status each week, with cycle and lead time derived automatically.
What makes it report-ready, not just a data dump:
- Pivot tables — group data by project, assignee, sprint, issue type, or other fields, so each stakeholder gets the view they need without exporting to a BI tool.
- Export — send grid data to XLSX or CSV, pivot reports to Excel or PDF, and charts to PNG, JPEG, PDF, or SVG. (Choose a Decimal time format — Decimal Hours, Days, or Weeks — on export if you’ll run formulas on the data.)
- Sharing and integrations — copy a live share link, embed reports in Confluence, or feed Power BI, Qlik, and Google Sheets through the app’s API / live data feed, so your status report stays current wherever stakeholders read it.
- Dashboard gadget — surface any report on a Jira dashboard alongside native gadgets.
- Issue widget — see time in status directly inside an issue, without opening the app.
- Saved presets — save frequent setups and reload (or share) them in one click.
Native Jira vs. Time in Status by SaaSJet
| Capability | Native Jira | Time in Status by SaaSJet |
|---|---|---|
| Status snapshot (counts by status) | ✅ | ✅ |
| Dashboard reporting | ✅ | ✅ |
| Cycle & lead time | ⚠️ Board-level (Control Chart) | ✅ Per status & status group |
| Time spent in each status (per issue, exact) | ⚠️ Approximate, visual (CFD) | ✅ |
| Average time across issues | ❌ | ✅ |
| Status & transition counts | ⚠️ Manual via JQL | ✅ Automatic |
| Cross-issue historical analysis | ⚠️ Per-issue history only | ✅ |
| Count repeated status entries | ❌ | ✅ |
| Exclude weekends / non-working hours | ❌ | ✅ Working calendars |
| Group statuses into stages | ❌ | ✅ Status Groups |
| Pivot tables | ❌ | ✅ |
| Charts (pie / bar / area) | ⚠️ Basic gadgets & reports | ✅ Per report & per issue |
| Excel / CSV export | ⚠️ Raw issue list only | ✅ Report data (decimal-ready) |
| Share to Confluence / Power BI / Sheets | ⚠️ Limited | ✅ Embed + API / data feed |
For basic visibility, native Jira may be enough. For actionable workflow insight, a dedicated reporting tool does the heavy lifting.
Jira status report example
Here’s what a finished weekly status report looks like in practice (illustrative data):
Project: Mobile App v3 · Week of 2026 · Status: 🟡 Amber
32 of 48 issues complete (67%). On track for the 2026 release, but QA is the constraint — bugs are averaging 3.1 days in “In QA” versus 0.5 days in “In Progress.” Two blockers open: API-217 (waiting on vendor, 6 days) and API-244 (needs design sign-off, 2 days). Next week: clear the QA backlog before pulling in new scope.
Notice the report leads with a decision (“QA is the constraint”), not raw activity. That framing is what separates a useful status report from a data dump.
Best practices for effective Jira status reports
- Report on trends, not isolated incidents. One slow ticket isn’t a pattern; the same delay across dozens of issues is. React to the pattern.
- Keep stakeholder reports to 5–7 metrics. More than that and the signal drowns. Add RAG or trend indicators so the status reads at a glance.
- Use reports to improve processes, not score individuals. Time in status reflects process health — handoffs, WIP limits, queues — not how hard a person worked. Using it punitively breaks the data’s usefulness.
- Always set a working calendar. A report that counts weekends and nights overstates every duration and misleads your conclusions.
- Standardize workflows where possible. Consistent status definitions make reports comparable across teams.
- Combine metrics. Read status data alongside cycle time, lead time, throughput, and sprint predictability for the full picture.
- Review on a cadence. Build reporting into retrospectives, status meetings, and quarterly reviews, and automate the recurring report so it survives a busy month.
Conclusion
An effective Jira status report serves two purposes: it provides stakeholders with a clear view of the current state of work and helps teams identify where work is getting stuck. Native dashboards, built-in reports, and Confluence templates address the first need by offering a high-level overview of progress and workflow at the board level. However, addressing the second challenge—obtaining accurate time-based execution data that truly reveals bottlenecks—typically requires a specialized app.
Try Time in Status by SaaSJet free and generate your first automated status report in a few clicks.
Frequently asked questions
How do I do a status report in Jira? Create a dashboard with status gadgets, use the board’s built-in Control Chart and Cumulative Flow Diagram for flow, generate a Confluence Status Report from the Jira report template, or use an app like Time in Status by SaaSJet for automated, time-based reports. Pick the method that matches whether you need a snapshot or workflow analytics.
Where can I find Jira statuses? Statuses are defined by your project’s workflow. View them under Project settings → Workflows, or see an issue’s current status on its card and detail view. For the full history of changes, open the issue’s history tab or run a time-in-status report.
How do I track status in Jira? For current status, use boards, filters, and dashboard gadgets. For board-level flow, use the Control Chart and CFD. To track exactly how long work stays in each status across issues, native Jira can’t quantify this cleanly — use a reporting app that reads workflow history, such as Time in Status by SaaSJet.
How do I run a Jira report? Built-in reports live under your board’s Reports section (Burndown, Velocity, Control Chart, Cumulative Flow Diagram, Created vs. Resolved, and more). For status-duration reports, open Apps → Time in Status, choose a report type, select your issues, and run it.
Does Jira have a built-in status report? Jira’s native reporting covers snapshots (dashboard gadgets) and board-level flow (Control Chart, CFD, Created vs. Resolved). In Confluence, the Jira report template includes a Status Report that shows progress in pie charts by status, priority, component, and work type. None of these measures exact time spent in each status across issues.
What is a Jira status transition report? It analyzes movements from one status to another (e.g., Open → In Progress, Testing → Done) to reveal workflow efficiency and bottlenecks. Native Jira has no cross-issue transition report; Time in Status by SaaSJet produces one via its Transition Count report.
Can I see how long an issue stayed in a status, or how many times it entered one? Not precisely with native Jira or JQL alone. Time in Status reads the issue’s change history to calculate exact time per status (Time in Status report) and how many times an issue entered a status (Status Count report).
How do I export a Jira status report? Native filter results export to CSV/Excel from the issue navigator, but as raw data. Time in Status exports report grids to XLSX/CSV, pivot reports to Excel/PDF, and charts to image/PDF, and shares live data to Confluence, Power BI, and Google Sheets via its API / data feed.