How to build Jitbit help desk dashboards in Metabase

Jitbit is an IT help desk available as SaaS or self-hosted, with tickets, categories, assets, and SLAs. Metabase is where you turn that activity into shared, trustworthy dashboards. Because Metabase reads from SQL databases, connecting them on Jitbit SaaS means a small pipeline: sync Jitbit into a database or warehouse on a schedule, then point Metabase at it. And uniquely, if you self-host Jitbit, Metabase can connect directly to its SQL Server database. This guide walks through both — including a free option with no paid connector.

How do you connect Jitbit to Metabase?

Metabase connects to SQL databases and warehouses — not to SaaS APIs directly. How you connect Jitbit depends on how you run it. On self-hostedJitbit, Metabase can connect directly to the underlying SQL Server / Azure SQL database (point it at a read replica) — no pipeline required. On Jitbit SaaS there's no direct database access, so connecting means running a small pipeline that copies Jitbit data into a database on a schedule, then connecting Metabase to that database. Either way, once the data lands, the models, metrics, and SQL later in this guide all work.

The good news: neither path requires a paid tool. On SaaS, use a managed connector if you want zero maintenance, or a free, code-based sync you host yourself — both are covered in Build the pipeline below, and in more depth in our guide to building a data pipeline.

What can you analyze from Jitbit data in Metabase?

• Ticket volume — created vs. closed by day and category
• First response time — how long requesters wait for a technician
• Resolution time — created to closed, with median and p90
• Category drivers — what's generating IT tickets
• Backlog and aging — open work and how long it's been waiting
• Technician performance — workload distribution and resolution speed
• Repeat requesters — users filing tickets repeatedly

Which Jitbit dashboards should you build in Metabase?

How do you build the Jitbit → Metabase pipeline?

Your route depends on whether you run Jitbit SaaS or self-hosted. On self-hosted, Metabase connects straight to the database; on SaaS, a pipeline is the same four stages — extract from the API, load into a database, model the raw tables into clean ones, and visualize in Metabase.

Self-hosted: connect directly

• Self-hosted Jitbit stores data in SQL Server / Azure SQL, which Metabase connects to natively. Point Metabase at a read replica and model on top — no ETL required.
• Never run heavy reporting against the live production database under load; use a replica or restored backup.

SaaS: sync via the API

• dlt (free, code) — write a Python pipeline against the Jitbit REST API to land tickets and comments in your warehouse.
• Jitbit REST API (free, raw) — the source of truth on SaaS; paginate tickets and comments and upsert on a schedule.

Notes

• On either route, build clean models rather than reporting off raw tables.
• Capture status changes if you want accurate reopen rate and time-in-status.

Can you generate a Jitbit dashboard with AI?

Yes — and once Jitbit data is reachable from a database (a sync on SaaS, or the SQL Server replica on self-hosted), this is the fastest way to a strong first draft. First give an AI assistant a way to read your Metabase schema and create questions and dashboards, then paste the prompt below. It builds the dashboard from your database tables and tells the agent to skip metrics the schema can't support instead of faking them.

Two ways to let an assistant query and build in Metabase

Both connect to a Metabase instance that's already pointed at your synced database — the pipeline above moves the data; these just let the assistant read and write Metabase. Pick whichever fits your setup:

Set up the Metabase MCP server

Enable it under Admin → AI → MCP, then point your client at the endpoint:

# Metabase built-in MCP (replace with your instance URL)
claude mcp add --transport http metabase https://your-metabase.example.com/api/metabase-mcp

{
  "mcpServers": {
    "metabase": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://your-metabase.example.com/api/metabase-mcp"]
    }
  }
}

Clients with native remote support can use a "url" field instead of the mcp-remote bridge. Confirm the current endpoint in the Metabase MCP docs.

Set up the Metabase CLI

Install it globally, then authenticate once (the binary is mb):

# Install the CLI (the binary is `mb`)
npm install -g @metabase/cli

# Authenticate once — opens your browser on Metabase v62+, or use an API key
mb auth login --url https://your-metabase.example.com
mb auth status

On Metabase v62+ mb auth login opens your browser; older servers fall back to an API key. A terminal-based assistant can then inspect your schema (mb db schemas, mb table get --include fields) and create content (mb card create, mb dashboard create) against the synced tables.

Prompt: build the Jitbit Help Desk Overview dashboard

With MCP or the CLI connected, paste this into your assistant to generate the dashboard:

Create a polished Metabase dashboard for Jitbit help desk analytics using the
available Jitbit tables in this database.

Goal: Help IT support leaders understand volume, responsiveness, SLA, category
drivers, and technician workload from Jitbit data.

First, inspect the schema and identify the available Jitbit tables. Do not assume
exact table names. Map the available raw tables into these analytical concepts
where possible: Tickets, Comments, Users (technicians and end users), Categories,
Statuses, Priorities, Tags, and Departments.

Important:
- Build the dashboard from durable database/warehouse tables (or, on self-hosted
  Jitbit, a read replica of the SQL Server database).
- Use medians (p50) and p90 for response and resolution times, never averages.
- Define "first response" as the first technician comment, excluding internal
  notes and automated messages.
- If status-change history is missing, do not calculate reopen rate or
  time-in-status. Use a caveat instead.
- Do not claim Metabase connects natively to the Jitbit SaaS API; on self-hosted
  it connects to the underlying SQL Server database directly.

Dashboard title: Jitbit Help Desk Overview

Sections:
1. Executive summary (KPI cards): Tickets created last 7 days; Closed last 7 days;
   Open backlog; Median first response time; Volume by category.
2. Volume & backlog: Created vs closed by day; Open by status; Backlog aging;
   Volume by category.
3. SLA & response time: First response p50/p90 by week; Overdue by category;
   Reopened by week (only if history exists).
4. Technician performance: Closed by technician; Median resolution time by
   technician; Open assigned by technician; Volume by priority.
5. Categories & drivers: Volume by category over time; Top recurring issue types;
   Tickets by department; Repeat requesters.

Filters: Category, Technician, Priority, Status, Department, Date range.

Before finalizing, create or recommend reusable Metabase models:
modeled_jitbit_tickets, modeled_jitbit_comments, modeled_jitbit_users, and
modeled_jitbit_categories.

Output: Build the dashboard if you have permission; otherwise provide the exact
questions, SQL, model definitions, and layout. Include caveats for any metric
that cannot be calculated from the available schema. Keep it practical, dense,
and executive-readable. Avoid vanity metrics.

How should you model Jitbit data in Metabase?

Core tables

Modeling advice

• Map StatusID and PriorityID codes to readable labels in a model.
• Define first response from the first non-internal technician comment (ForTechsOnly = false, technician author).
• Treat tags as a bridge table so a ticket can carry many tags.
• On self-hosted, build models on a replica so dashboards don't load the OLTP database.
• Define "closed" once (e.g. StatusID = 3) and reuse it everywhere.

Which Jitbit metrics should you track in Metabase?

What SQL powers Jitbit dashboards in Metabase?

These use Jitbit's SQL Server table names (shown in PostgreSQL-style syntax). On SQL Server, swap percentile_cont and date functions for the T-SQL equivalents.

SELECT
  CAST(t.IssueDate AS date) AS day,
  COUNT(*)                                          AS created,
  COUNT(*) FILTER (WHERE t.StatusID = 3)            AS closed
FROM Tickets t
WHERE t.IssueDate >= CURRENT_DATE - INTERVAL '30 days'
GROUP BY CAST(t.IssueDate AS date)
ORDER BY 1;

WITH first_tech_comment AS (
  SELECT
    c.IssueID,
    MIN(c.CommentDate) AS first_reply_at
  FROM Comments c
  JOIN Users u ON u.UserID = c.UserID
  WHERE u.IsAdmin = true       -- technician
    AND c.ForTechsOnly = false
  GROUP BY c.IssueID
)
SELECT
  date_trunc('week', t.IssueDate) AS week,
  percentile_cont(0.5) WITHIN GROUP (
    ORDER BY EXTRACT(EPOCH FROM (f.first_reply_at - t.IssueDate)) / 60.0
  ) AS median_first_reply_min
FROM Tickets t
JOIN first_tech_comment f ON f.IssueID = t.TicketID
GROUP BY 1
ORDER BY 1;

SELECT
  cat.CategoryName   AS category,
  COUNT(*)           AS tickets
FROM Tickets t
JOIN Categories cat ON cat.CategoryID = t.CategoryID
WHERE t.IssueDate >= CURRENT_DATE - INTERVAL '90 days'
GROUP BY cat.CategoryName
ORDER BY tickets DESC;

SELECT
  CASE
    WHEN CURRENT_DATE - t.IssueDate::date <= 1  THEN '0-1 days'
    WHEN CURRENT_DATE - t.IssueDate::date <= 3  THEN '2-3 days'
    WHEN CURRENT_DATE - t.IssueDate::date <= 7  THEN '4-7 days'
    ELSE '8+ days'
  END                AS age_bucket,
  COUNT(*)           AS open_tickets
FROM Tickets t
WHERE t.StatusID <> 3
GROUP BY 1
ORDER BY MIN(CURRENT_DATE - t.IssueDate::date);

What are common mistakes when analyzing Jitbit in Metabase?

Related

Related analytics

Related integrations

FAQ