What goes in an IT ticket dashboard in Metabase?

An IT ticket dashboard follows the tickets themselves through their lifecycle: how volume trends, how the backlog ages, how often closed tickets bounce back, where escalations and SLA breaches concentrate, and what resolution time really looks like as a distribution. Metabase builds it from the ticket and status-history tables of Jira, Zendesk, or Freshdesk, synced to a warehouse.

What does an IT ticket dashboard look like?

Here’s the layout this guide builds. The lifecycle’s headline numbers sit at the top. Volume and mix come next — intake versus closes, the priority split, and how the open backlog’s age profile has shifted. Quality and SLA close the page: reopened and escalation rates, where resolution time actually lands, which priorities are breaching, and the specific tickets that breached this week.

Which cards belong on an IT ticket dashboard?

The eight below trace the lifecycle end to end: arrival, aging, bounce-back, escalation, breach, and how long resolution really takes.

• Tickets opened vs. closed per week (combo)
• Open tickets by priority (donut)
• Open tickets by age bucket per week, from backlog snapshots (stacked bar)
• Reopened rate by week against its goal (line)
• Escalation rate by week (line)
• Resolution-time distribution, past 30 days (bar)
• SLA breaches by priority, this week (bar)
• Tickets that breached SLA this week (table)

What data does the dashboard need?

• A tickets table: ticket_id, priority, category, opened_at, resolved_at, status, and the desk’s SLA due/breach fields.
• A ticket_events (status history) table — Jira’s changelog, Zendesk’s audits, Freshdesk’s activities — with ticket_id, from_status, to_status, occurred_at.
• Derived lifecycle timestamps per ticket: first_closed_at, reopened_at, escalated_at — computed once from the events table.
• A backlog_snapshots table appended daily or weekly: snapshot date, ticket (or age bucket), and age in days — the aging trend cannot be reconstructed later.
• An SLA policy reference (target per priority for response and resolution) so breach cards agree with the desk’s own math.

How do you build it?

1. Sync tickets and the status-history stream from your desk into the warehouse — the lifecycle cards need transitions, not just current state.
2. Build a Metabase model that derives first_closed_at, reopened_at, and escalated_at per ticket with window functions over the events table.
3. Schedule the backlog snapshot: one job appending open-ticket ages per day, feeding the aging stacked bar.
4. Create the quality cards from the model — reopened rate within 7 days of first close, escalation rate per week, and the resolution-time histogram bucketed by hours.
5. Add filters for priority, category, and date range, and pin the breach table’s filter to the current week so the review always opens on fresh cases.

Example card SQL

SELECT
date_trunc('week', t.first_closed_at)::date   AS week,
COUNT(*)                                      AS tickets_closed,
COUNT(*) FILTER (
  WHERE t.reopened_at IS NOT NULL
    AND t.reopened_at
        <= t.first_closed_at + INTERVAL '7 days'
)                                             AS reopened_within_7d,
ROUND(
  100.0 * COUNT(*) FILTER (
    WHERE t.reopened_at IS NOT NULL
      AND t.reopened_at
          <= t.first_closed_at + INTERVAL '7 days'
  ) / COUNT(*), 1
)                                             AS reopened_rate_pct
FROM tickets t
WHERE t.first_closed_at >= CURRENT_DATE - 84
GROUP BY 1
ORDER BY 1;

Related

Metrics

Integrations

Dashboards

FAQ