BugHerd Dashboard — Bug Trend Analytics

01Overview

A bug board tells you what is open right now. It does not tell you whether a project is converging or quietly filling up, which is the only thing worth knowing before a client call. This dashboard sits on top of BugHerd and answers the second question.

02The problem

227 client projects lived in BugHerd, each as its own board. Getting a read on one meant opening it and counting; getting a read across the account meant opening 227. Worse, the API only reports a task's current state — so nothing anywhere recorded that a bug moved from reported to review last Tuesday. Without that, a trend line is guesswork, and 'are we closing faster than they are reporting?' is unanswerable.

03Approach

1. 01

   Mirror

   A sync engine copies every project and task into local PostgreSQL rather than calling the API on each page view. Pages resolve to a single SQL query; a full sync runs in the background when the mirror goes stale, and only new or changed tasks hit the API. A webhook endpoint means a change on the board reaches the dashboard in seconds instead of at the next sync.

2. 02

   Remember

   Every status change is written to its own history table as the mirror sees it. That one table is what makes the rest possible — the trend charts are computed from recorded transitions rather than inferred from today's snapshot, so the lines describe what actually happened.

3. 03

   Read the project

   Each project resolves to its real shape: total tasks split into open, closed and non-development, then broken across the workflow columns — clarification, reported, revisit, in-progress, for review — with every column split again by severity. 117 sitting in review is a different problem from 31 newly reported, and the layout refuses to average them together.

4. 04

   Trend

   Creation is plotted against resolution over a selectable window, alongside a status trend for open, revisit and to-close-off. The gap between those lines is the decision: a project where new bugs outrun closed ones needs people, not a status update, and it shows up as divergence weeks before it shows up as a missed deadline.

5. 05

   Distribute

   Priority, status and browser breakdowns give the texture behind the totals — whether a backlog is genuinely critical or mostly unset, and whether an issue is universal or one browser's problem.

6. 06

   Roll out

   Getting BugHerd onto a client site had been a manual dev ticket per project, occasionally dropped. The handoff spec replaced it with a per-site CMS setting on the shared base template, mirroring how analytics is already injected: turning BugHerd on for a site becomes a value someone fills in, not a code change someone has to remember.

04Screens

05Results

• 227

  client projects readable from one place instead of one board at a time.

• Page loads became a single query against a local mirror rather than a fan-out of API calls.

• Trend charts are computed from recorded status transitions, so history is real rather than estimated.

• A project's backlog resolves to something actionable — 210 tasks, 172 open, 117 waiting on review, 30 critical — which is a staffing decision rather than a number.

NoteInternal tool. The first sync of a whole account is genuinely slow — it walks every project and task before the dashboard is useful — so the design leans on that being a one-off: after it, incremental sync and webhooks keep the mirror current at a fraction of the cost.

06Built with