Reverse-engineering a restricted Jira dashboard from a screenshot — saved filters first, gadgets second
The Technical Support team at the company had an existing escalations tracker dashboard in Jira, visible through Confluence, but access to it was restricted. The dashboard provided a real-time view of escalated bugs, service requests, and stories — including aging metrics, backlog distribution by product area, and created vs. resolved trends across the full escalation lifecycle.
Without access to the original dashboard, the support team lacked visibility into how escalated issues were moving through engineering, how long bugs were sitting unresolved, and where technical support volume was concentrated by product area. Requesting permissions would add delay. The faster path was to rebuild it from scratch.
Rather than waiting on access, the decision was made to reverse-engineer the dashboard from a screenshot of the original. The screenshot revealed the full layout: four chart gadgets on the left (average age charts, a pie chart by project, and a created vs. resolved trend) and three issue list gadgets on the right (bugs, service requests, and stories), each pulling from a distinct saved filter.
The key insight was that every gadget on a Jira dashboard is powered by a saved filter. Building the filters first — and getting the JQL right — meant every gadget would populate correctly without needing to touch the original. The approach was also designed to be adaptable: since the company's escalations originate in Intercom before reaching Jira, the filter criteria needed to match however the team tags tickets when they escalate to engineering, not just generic issue type queries.
Three saved Jira filters using JQL scoped to the team's escalation label:
issuetype = Bug AND labels = "technical-support" ORDER BY created DESCissuetype = "Service Request" AND labels = "technical-support" ORDER BY created DESCissuetype = Story AND labels = "technical-support" ORDER BY created DESCA two-column Jira dashboard named "Technical Support Escalations Tracker." The left column carries the trend views: an average age chart for bugs (last 180 days, grouped daily), an issue statistics pie chart broken down by product area, a created vs. resolved chart for bugs (last 180 days, grouped monthly), and an average age chart for service requests. The right column carries filter results tables for bugs, service requests, and stories, each showing project, created date, reporter, summary, priority, assignee, and status.
A reference guide was also documented to make the rebuild reproducible for any future team member, or to recreate the dashboard in a new Jira project. The filters were designed with the Intercom-to-Jira escalation context in mind: a step was documented to verify the actual label or component convention used on escalated tickets before finalizing the JQL, since the filter criteria must match the team's real tagging practice to return accurate data.
The rebuild process produced a complete, documented specification for recreating the dashboard without requiring access to the original. The approach avoided a permissions request cycle and produced a reusable artifact the team can reference going forward. The dashboard, once built, provides:
This work also connects directly to a broader documentation cleanup initiative, ensuring support tooling accurately reflects how the team operates in Intercom today.
Reverse-engineering a dashboard from a screenshot is faster than it sounds when you understand the underlying structure. Jira dashboards are just saved filters plus gadgets — once you identify the filter logic, the rest follows quickly.
The more important takeaway is that visibility into escalations is a prerequisite for improving them. Escalation quality work requires the same kind of structured view into what is happening after a ticket leaves support. Building this dashboard is as much about operational discipline as it is about tooling.