How can you create a live release status dashboard in Jira?

A live release status dashboard in Jira gives you a continuously updated view of the information you need to follow a release, instead of rebuilding that status manually for every meeting or report.

The release reporting problem I was dealing with

At the time, we were managing major releases every quarter, and each one followed a pretty familiar rhythm. Early on, a short weekly status meeting was enough. We would go through the main points, confirm what was moving as expected, and flag anything that needed attention.

But as we got closer to go-live, that changed quickly. The weekly meeting became two or three meetings a week, and what used to take around 15 minutes could easily stretch close to an hour. There was simply more to check: progress, open actions, deployments, blockers, bugs, and anything that could put the release at risk.

The problem was not that we lacked information. We had plenty of it. The problem was that it was spread across different places, and every status update required someone to bring it all together before we could have a useful conversation.

That was the point where release reporting started to become work in itself.

What our release report had to answer every week

As those meetings became more frequent, the report behind them also became more important. We were essentially coming back to the same information every week: the release timeline, the status of each function involved, open actions, deployments, blocking bugs, and the overall bug trend.

Looking back, I think the easiest way to understand that report is through the questions we were trying to answer with it. From my experience managing this type of release process, these were the six questions our status report had to answer every week:

1. Where are we in the release timeline?
   We needed to see the main milestones and understand what was coming next as we moved toward go-live.
2. What is the current status of the release?
   The report showed the status by function, so we could see where things were progressing normally and where something needed attention.
3. What actions are still open, and who owns them?
   We tracked the actions coming out of the release process, together with their owners and status, so nothing important disappeared between meetings.
4. What has been deployed, and where?
   The deployment summary gave us visibility into what had been deployed across the different environments.
5. What is currently blocking the release?
   Critical and blocking bugs needed to be easy to spot because they could directly affect whether the release could move forward.
6. Is release quality improving or deteriorating?
   We also followed the trend of open and resolved bugs to understand whether we were actually getting closer to a stable release.

None of these questions was unusual. They are the kind of things you naturally need to know when you are responsible for a release. The frustrating part was how much work it took us to bring all of those answers together every time we needed an updated view.

The release timeline lived in PowerPoint. Open actions were tracked in Excel. Bugs came from Jira. Deployment updates often came from discussions during the meeting itself. Then, once we had gone through everything, someone still had to bring it all together again in the meeting minutes and send the update by email.

That meant every new status depended on someone manually collecting information from several places, checking that it was still accurate, and rebuilding the overall picture of the release.

For me, that was the real problem. The information existed, but there was no continuously updated view we could simply open when we needed to understand where the release stood.

And that is where the idea of a live release status dashboard started to make sense.

So, what should a live release status dashboard in Jira do?

For me, the answer is fairly simple: it should bring the key release information into one place and keep that view current enough that you can use it without rebuilding the status every time.

In practice, that means you should be able to open Jira and quickly see:

• where you are in the release timeline
• what is progressing as expected
• which actions are still open
• what has been deployed, and where
• what is currently blocking the release
• whether the overall quality picture is improving

The important part is that the dashboard should not become another report someone has to maintain manually. If the information already exists in Jira or another system used in the release process, the dashboard should reflect those updates in real time.

I have seen the opposite happen many times: the right information is already available in Jira, but someone still exports the graphs, copies them into PowerPoint, adds a few updates from somewhere else, and sends the result around again. At that point, you have good data, but you are still managing the status manually.

A live dashboard changes that. Critical bugs, deployment status, open actions, and other release information can remain visible in the same place rather than being recreated for every meeting or email update.

That does not mean every release meeting suddenly disappears. But it does mean you can stop using meetings just to read out information that everyone could already see for themselves.

How much of this can Jira already do?

Quite a lot, actually.

Jira already gives you the basic building blocks for a useful release dashboard. You can create custom dashboards, add gadgets, and use saved filters to surface the work items that matter for a release. Atlassian also lets you turn search results into dashboard gadgets, which means you can create views around things like open issues, blockers, ownership, status, or unresolved work without moving that information somewhere else.

Depending on how your Jira setup is structured, that already covers a good part of the questions I was trying to answer in my release reports.

For example, Jira can help you surface:

• open work and its current status
• issues assigned to specific owners
• blockers or other issues matching a defined filter
• trends based on filtered work items
• release-related work grouped through saved searches and dashboard gadgets

Jira can also show deployment information when it is connected to a supported CI/CD provider. Atlassian documents deployment status directly on the release page, including whether a work item was deployed successfully and the environment it was deployed to.

Can Jira alone build a release dashboard?
Yes, in many cases. If the information you need already exists in Jira and can be surfaced through work items, filters, gadgets, versions, and connected deployment data, you may not need another tool to build a useful release dashboard.

So I would not start from the assumption that you need another tool just to build a release dashboard. If the information you need already exists in Jira and can be expressed through work items, filters, gadgets, and connected deployment data, Jira can take you surprisingly far.

The gap becomes more visible when you also need to understand what is happening across deployments and environments, not only what is happening with the work items in Jira.

Where Jira starts to fall short for release execution

That was exactly where I started to feel the limitation in the release process I was managing.

Deployment information was a good example. In our case, the deployment status by environment was still something we brought into the release meeting manually. Knowing that an issue was done was one thing. Knowing which version was actually deployed in each environment was another.

The same applied to the environments themselves. We also needed to understand whether an environment was available and ready for the next activity, how it was being used, and whether something else planned for that environment could interfere with the release.

At that point, I was looking at two connected views of the same release: the work we were tracking in Jira, and what was actually happening across deployments and environments.

Bringing those two views together is where the dashboard becomes much more useful.

How I would build the dashboard

Once I know which questions the dashboard needs to answer, I would not start by choosing charts. I would start by figuring out where each answer comes from.

That sounds obvious, but it changes the way you build the dashboard. Instead of asking “What can I put on this Jira dashboard?”, I would go back to the six questions and map each one to a reliable source.

1. Map each release question to its source

I would start with a simple list:

• Release timeline: where are the milestones and release dates maintained?
• Current release status: which Jira work items or statuses represent progress?
• Open actions: which work items, owners, and due dates need to be visible?
• Deployments: where does the deployment information come from?
• Blockers: which Jira fields, priorities, labels, or filters identify them?
• Quality trend: which work items represent defects, and what do I want to compare over time?

For information that already lives in Jira work items, saved searches and filters are a natural starting point. Jira lets you save searches as filters and use search results as dashboard gadgets, so the view can be based on the same work data people are already updating.

2. Build the filters before the dashboard

I prefer to get the underlying view right before thinking about presentation.

For example, if I want a dashboard block showing unresolved release blockers, I first need a filter that reliably returns those blockers. The same applies to open actions, defects, or work associated with a particular release.

Once those filters are working, Jira can use them as sources for dashboard gadgets and charts.

This also makes the dashboard easier to maintain. If the definition of a blocker changes, I can update the filter instead of rebuilding the dashboard logic in several places.

3. Use Jira's release and deployment data where it already exists

I would avoid recreating information Jira can already show.

Jira lets you assign work items to versions through the Fix versions field, and its release views can show progress toward a version. When development and deployment tools are connected, Jira can also display related builds and deployments and show which work has been deployed to which environment.

So before adding another source, I would check what Jira is already receiving from the release and CI/CD setup.

4. Be clear about what Jira does not contain

This is where the mapping exercise becomes useful.

If one of the six questions cannot be answered from Jira work items, versions, filters, or connected deployment data, I would mark that gap instead of trying to approximate the answer with an unrelated metric.

If one of those questions depends on information that is not maintained in Jira, such as environment availability, readiness, scheduling, or operational dependencies, I would treat that as a gap and identify where that information actually lives.

5. Choose the visualization based on the decision

Only after the data is clear would I decide how to display it.

I would keep the most important release questions visible first:

• Are we on track?
• Is anything blocking us?
• What is deployed where?
• What still needs action?

A list is often better for actions or blockers because I need to see the actual items and owners. A chart makes more sense when I am looking for a trend, such as how defects are changing over time. A release or deployment view is more useful when the question is about versions and environments.

Jira dashboards support different gadgets and layouts, so I would choose the format based on what someone needs to understand or decide, not simply because a particular chart looks good.

6. Make sure the dashboard stays live without extra reporting work

For me, this is the final test.

If someone still has to export a chart, update a PowerPoint, or manually rewrite the same status somewhere else before the dashboard is useful, I have not really solved the original problem.

The goal is for the dashboard to reflect the sources we already use to manage the release. When a work item changes status, a blocker is resolved, or connected deployment data reaches Jira, the release view should move with it.

Once that foundation is in place, the visual design becomes the easy part. The harder and more important job is making sure every part of the dashboard answers a real release question with information you can trust.

When a Jira release dashboard needs more than Jira data

Once the basic dashboard is working, the next step is to look at the information that still sits outside the view.

In my case, that was mainly environment and deployment context. Jira already gave us a strong view of the work, but I also wanted the dashboard to reflect what was happening across the environments involved in the release.

When do you need additional tooling?
If the release dashboard depends on structured information that is not maintained in Jira or a connected source, additional tooling may be useful. In practice, this often means environment status, availability, scheduling, dependencies, or other operational context that needs to sit alongside the Jira work.

This is where Apwide Golive becomes useful. It brings environment information into Jira, so the release view can include things like environment status, deployed applications and versions, planned activities, and the relationship between Jira work items and specific environments.

That adds another layer to the dashboard we have been building throughout this article.

Instead of seeing only that a work item is complete, I can also understand the deployment context around it. Instead of checking a separate spreadsheet to know whether an environment is available, that information can be part of the Jira view. And when several activities depend on the same environment, planning and conflict information can be visible before it becomes a problem.

For me, that is the real value of adding a release and environment management layer to the dashboard. The goal is not to replace the Jira information we already have, but to give it the operational context that was previously scattered across other tools and conversations.

Once that context is available in Jira, the dashboard becomes much closer to the view I originally wanted during those release meetings: one place where I can understand both the progress of the work and what is actually happening around the release.

What changed once the status became live

What changed most was not the amount of information we had. It was how easy it became to use it.

Once the release status was visible in one place and updated from the sources we were already working with, we no longer needed to spend the same amount of time preparing the status before we could talk about it. People could check the dashboard first, understand where things stood, and come to the conversation with the same context.

That does not mean every release meeting becomes unnecessary. I still see a lot of value in meetings when there is a decision to make, a risk to discuss, or a dependency that needs coordination.

What I would avoid is using those meetings simply to collect information that could already be visible.

That was the main lesson for me. A useful release dashboard is not really about having more charts. It is about making the answers you need during release execution available without rebuilding the status every time someone asks for it.

If your release process already depends heavily on Jira but you are still managing environment and deployment context somewhere else, Apwide Golive can bring that information into Jira and make it part of the same release view.