Jira dashboards are easy to create and surprisingly easy to get wrong. Most of them end up as a wall of gadgets nobody reads, which is a waste — this is the one place in Jira where data from multiple projects lands on a single screen.
Why use dashboards in Jira?
A Jira dashboard pulls scattered Jira data into one customizable view. Instead of opening five boards and running three filters, project managers get a single screen that answers “where are we?”.
Done well, it helps teams:
- Monitor progress in real time
- Spot blockers before they become delays
- Make decisions on data rather than on the loudest voice in the room
- Keep stakeholders aligned without another status meeting
Whether you’re a project manager watching deadlines, a developer tracking your own Jira tasks, or a team lead balancing workload, a focused dashboard saves time and keeps everyone looking at the same numbers.
Okay, but building a dashboard takes five minutes. Building one people actually open every morning takes a lot more thought, and Jira doesn’t make that part easy :(
How to create a Jira dashboard
- Open the Dashboards dropdown in the left navigation and press + to Create dashboard.
- Name it and describe it. The description is where you say who it’s for.
- Set permissions before you save. Dashboard sharing is the step people skip, and then nobody else can open the thing.
- Click Add gadget and pick from the list. Most gadgets need a saved filter, so create your filters first — it saves a lot of back-and-forth.
- Change the layout from the top right and drop gadgets where they make sense. Put the one thing you check every morning top left.
- Save and share.
One practical note: nearly every gadget is driven by a saved filter, so the quality of your dashboard comes down to the quality of your JQL. Spend the time there.
The most useful Jira dashboard gadgets
Native gadgets cover more ground than people expect. Here are the ones worth your dashboard space, grouped by what you’re trying to see.
Team progress
- Sprint Health — sprint progress at a glance: completed, in progress, remaining work, plus scope change.
- Pie Chart gadget — issue distribution by assignee, status, priority or any field you choose. The classic workload pie chart.
- Created vs Resolved — the created vs resolved chart shows whether you’re keeping up with incoming work over a date range. If the gap widens month after month, that’s your real capacity story.
Project overview
- Filter Results gadget — a list of project issues from a saved filter. One per dashboard is plenty.
- Two-Dimensional Filter Statistics — cross-tabulate Jira issues by two fields, like status against assignee. The closest thing to a pivot table in native Jira.
- Average Age Chart — how long open work items have been sitting, which is where bottlenecks show up.
- Average Time in Status — average days resolved issues spent in each status.
Service teams
If you’re reporting on customer requests rather than development work, Jira Service Management adds its own: the First Response Chart for how quickly agents reply, and SLA-based saved filters shown through Filter Results for anything breached or at risk.
Housekeeping
- Wallboard Spacer gadget — empty space for wallboard layouts. Sounds trivial, makes a TV-mounted dashboard readable.
- Assigned to Me — work items assigned to the current user. Good on a personal dashboard, pointless on a team one.
Where you can hit a bump with native Jira dashboards
Native gadgets are great at counting things. Ask them anything beyond that, and you’ll run into limits fast:
- No timeline. Gadgets show how many tasks are in each status, not when they’re due. No Gantt, no dependencies.
- Workload without capacity. You’ll see who has the most tasks, but not who’s out next week or who’s already over their hours.
- Basic time tracking. No proper timesheets and no planned vs actual.
- Sprint gadgets stick to one board. Comparing several teams on one screen doesn’t really work.
- Little room to customize. No custom formulas or formatting, and every gadget needs its own filter to maintain.
- Look, don’t touch. You can’t move dates or reassign work from a dashboard.
- Sharing depends on permissions. Anyone without access to the filter or project sees nothing, so stakeholders outside Jira are out of luck.
- More gadgets, slower page. Pile them on and the dashboard starts to drag.
How Planyway for Jira can help you
Jira native dashboards excel at showing status snapshots, such as how many bugs are open, what sprint progress looks like. But they struggle to answer dynamic planning questions: Who is doing what, when, and can we actually deliver on time?
Planyway for Jira addresses this gap by adding a real-time planning and capacity layer directly on top of Jira data.
- One timeline across projects. Group work by project, epic, team, person or component. Add milestones, releases, sprints and cross-project dependencies, and switch to a Gantt layout when you need more detail. Unlike Plans, it doesn’t require Premium.
➡️ Try Planyway free
- Workload you can fix on the spot. See who’s over or under capacity, with vacations already counted. If someone’s overloaded, stretch or move their tasks right on the timeline, and the new dates go to Jira.
- Time tracking with a real report. Time logged in Planyway and in Jira stays in sync, and a planned vs tracked report shows where your estimates went off.
- Easy to share. Save views for different teams and send them by link, or export to PDF, Excel or CSV for people outside Jira.
There’s also a free plan for teams of up to 10 users.
How to share Jira dashboards
Sharing options in Jira Cloud:
- Private is the default option — only you. Fine while you’re building it.
- Group shares with members of a specific group. On Jira Cloud you can only share with groups you belong to. Good for one team or department.
- My organization shares with everyone in your Atlassian organization. The usual pick for a dashboard the entire team or entire organization should see.
- Public means anyone on the internet, including anonymous users. Worth knowing: people can only see the underlying issues if the underlying projects allow that access in their permission schemes. So a public dashboard often looks empty to outsiders — the dashboard is shared, the project issues aren’t.
- Any logged-in user exists on Data Center, not Cloud. Same caveat about project permissions applies.
That last point trips up a lot of people. Sharing a dashboard never grants access to data. Permission schemes still decide what other users actually see, and two people can open the same live dashboard and see different numbers.
Dashboards vs reports vs boards
Three tools, three jobs. Picking the wrong one is a common reason a dashboard disappoints.
Tool | Best for | Limitations |
|---|
Board | Daily task management | One project, one workflow |
Report | Post-sprint analysis | Static, project-specific |
Dashboard | Live cross-project tracking | Needs setup to be useful |
Boards visualise and manage workflow — Scrum and Kanban columns that update as work items move. Built for the people doing the work: developers, scrum masters, delivery leads.
Jira reports analyse what already happened: velocity, burndown, cycle time. They’re generated per project under Project → Reports, and they’re snapshots rather than live views. Good for project management (retrospectives) and stakeholder reviews.
Dashboards track live project progress across multiple projects. They auto-refresh, they combine gadgets from different Jira projects, and they’re customizable per audience.
Use all three: a board for daily work, project reports for retrospectives, a dashboard for leadership updates.
Jira dashboards in Confluence
If your stakeholders live in Confluence, you can put Jira data on a Confluence page with the Jira macro rather than sending them into Jira. Handy for quarterly reviews, where numbers need context around them that a dashboard can’t carry.
How to make a bad Jira dashboard
Five reliable ways to lose your audience.
Too many gadgets. A dashboard with fifteen gadgets is a wall, not a story. Cap it at six and make a second dashboard if you need more.
Too much text. Lists of issues force people to interpret raw Jira data instead of seeing the point. One issue list per dashboard, maximum.
Irrelevant charts. If your team doesn’t act on a data point, it doesn’t earn a slot. Unrelated charts next to each other read as noise.
Bad charts. Pie charts with eight near-identical slices. Bar charts with no labels. Wrong chart type for the data — a bar chart beats a pie chart for comparisons almost always. Clean the data first: three different “Done” issue statuses will quietly ruin every chart you build.
Misleading data. No layout saves faulty numbers. If the underlying data is incomplete, don’t visualise it. You lose trust once and spend months getting it back.
How to make a good Jira dashboard
Define the audience first. The entire team needs collective progress and blockers. An individual team member needs their own work. Supervisors need outcomes, not ticket counts. One dashboard can’t do all three.
Tell a story, in order. Say you’ve noticed some requests taking far longer than others. Set the context with workload distribution across assignees. Lead into the problem with average time to resolution. Show the actionable insight with first response times by team member. Then let people discuss what to do about it.
Make charts readable. Right chart type, labelled axes, percentages where they help. Link to a Confluence page when a metric needs a definition — that’s also how you stop the same question coming up every month.
Revisit it quarterly. Dashboards rot. Priorities change, filters go stale, and nobody notices because the gadgets still render.
What’s your favourite gadget or dashboard setup? Share your tips in the comments.
