Build a Defect Tracking and Quality Monitoring Dashboard

Every production line produces defects. On their own they're easy to wave off, a bit of scrap here, an hour of rework there. But add them up and the cost is real, and that's the part most teams never see. The defects are sitting in a spreadsheet nobody sorts, or locked inside a quality system you can't get a live view out of. So the recurring problems stay invisible until someone runs a report, and by then the bad batch has already shipped.

The finished defect tracking dashboard showing stat cards, Pareto chart, and trend line

In this tutorial, you'll build a defect tracking and quality monitoring dashboard using FlowFuse in about 30 minutes. It reads defects from a database, calculates the KPIs a quality engineer actually looks at, and renders them live, filtered by line, shift, and date range.

You can interact with the live demo here: Try the Quality Monitoring Dashboard.

By the end, you'll have a foundation you can extend into broader production monitoring or OEE tracking, or a plant-wide quality report.

What You'll Need

Before you start building, make sure you have the following ready:

• A FlowFuse account. Sign up for FlowFuse Cloud, or use a self-hosted instance.

• A FlowFuse instance up and running. If you don't have one yet, create a new instance from your FlowFuse Platform.

• FlowFuse Dashboard installed. This tutorial uses @flowfuse/node-red-dashboard nodes (ui-text, ui-chart, ui-table, and ui-template) to build the interface. If it is not already installed, add it from the Node-RED Palette Manager. If you are new to FlowFuse Dashboard, follow the Getting Started guide to become familiar with the basics before continuing.

Note: FlowFuse Tables is currently in beta and available to Enterprise tier teams on FlowFuse Cloud, as well as Enterprise licensed self hosted teams running on Kubernetes. If you're on a different tier, you can follow along using any external database instead, Postgres, MySQL, or whatever you already have, with the standard database nodes from the palette. The SQL and flow logic in this tutorial will work the same either way.

How the Application Works

This dashboard is a read layer. It doesn't capture defects itself; it sits on top of a table of them and turns that table into something a supervisor can read at a glance:

• Defects live in one table. Each defect is a row: where it happened, what it was, how severe, its root cause, how it was handled, and what it cost. Something else fills this table: an operator logging defects from a form, or automatic events arriving over MQTT. For the tutorial, a simulator stands in for that source.
• One query calculates everything. A single query filters the table once and computes every KPI on the dashboard in one pass, then splits the result across every card, chart, and table, so the whole dashboard updates from a single source of truth.
• The header drives it all. Line, shift, and date-range dropdowns live in the dashboard header. Change any one and every widget recalculates together.

Importing the Simulator

You need a table and data in it before the dashboard can show anything. Rather than build that by hand, import the simulator flow; it creates the defects table and fills it for you.

It gives you two generators. A historical seed fills about six months of defects, so the charts have something to show right away. A live feed then inserts a fresh defect every few seconds, so the dashboard keeps updating on its own while you build.

Both run automatically on deploy: no buttons to click. The table is created first, the historical seed lands a few seconds later, and the live feed takes over from there. Within moments your table holds over a thousand records and keeps growing.

The schema it creates

You don't run this yourself; the import handles it. But it's the contract the whole dashboard depends on, so it's worth knowing what the defects table looks like, especially if you later point the dashboard at your own database:

CREATE TABLE IF NOT EXISTS defects (
    defect_id         VARCHAR(20) PRIMARY KEY,
    date              DATE NOT NULL,
    line              VARCHAR(20),
    station           VARCHAR(30),
    shift             VARCHAR(20),
    sku               VARCHAR(20),
    defect_type       VARCHAR(50),
    defect_category   VARCHAR(30),
    severity          VARCHAR(10),
    detected_stage    VARCHAR(20),
    root_cause        VARCHAR(50),
    disposition       VARCHAR(20),
    status            VARCHAR(20),
    cost_impact       NUMERIC(10,2),
    resolution_hours  NUMERIC(6,1)
);

CREATE INDEX IF NOT EXISTS idx_defects_date ON defects(date);
CREATE INDEX IF NOT EXISTS idx_defects_line ON defects(line);
CREATE INDEX IF NOT EXISTS idx_defects_shift ON defects(shift);

Each row is one defect. The columns group into where it happened (line, station, shift, sku), what it was (defect_type, severity, detected_stage), how it was handled (root_cause, disposition, status), and what it cost (cost_impact, resolution_hours). The three indexes cover the columns the dashboard filters by, so queries stay fast as the table grows.

Building the Query

Running one query per widget means a dozen database trips on every refresh. This dashboard runs a single query instead. It returns one row where each field holds one widget's data, and every widget reads just its own field.

Two CTEs at the top do the filtering. filtered_all applies all three filters: line, shift, and date range. filtered_line_and_shift skips the date filter, so the live ticker always shows the latest defects. After that, one json_agg block builds the data for each widget:

Tip: You don't have to write SQL yourself. Use FlowFuse Expert and describe the interface in plain English. It will generate the ui-template code for you.

WITH
  filtered_all AS ( -- full 3-filter set, used by almost every widget
    SELECT * FROM defects
    WHERE ($line = 'All' OR line = $line)
      AND ($shift = 'All' OR shift = $shift)
      AND date >= CURRENT_DATE - ($daysback || ' days')::interval
  ),
  filtered_line_and_shift AS ( -- ticker: "right now" view, ignores the date filter
    SELECT * FROM defects
    WHERE ($line = 'All' OR line = $line) AND ($shift = 'All' OR shift = $shift)
  )
SELECT
  -- stat cards + cost of poor quality (one pass over the filtered rows)
  (SELECT json_agg(t) FROM (
    SELECT
      COUNT(*) FILTER (WHERE status IN ('Resolved','Verified'))     AS closed_count,
      COUNT(*) FILTER (WHERE status NOT IN ('Resolved','Verified')) AS open_count,
      COUNT(*)                    AS total_count,
      ROUND(SUM(cost_impact), 2)  AS total_copq
    FROM filtered_all
  ) t) AS stat_cards_and_copq,

  -- average resolution time + SLA breach per severity
  -- (SLA targets: Critical 24h, Major 72h, Minor 168h)
  (SELECT json_agg(t) FROM (
    SELECT severity,
      ROUND(AVG(resolution_hours), 1) AS avg_resolution_hours,
      COUNT(*)                        AS resolved_count,
      COUNT(*) FILTER (WHERE resolution_hours >
        CASE severity WHEN 'Critical' THEN 24 WHEN 'Major' THEN 72 ELSE 168 END) AS sla_breached_count,
      ROUND(100.0 * COUNT(*) FILTER (WHERE resolution_hours >
        CASE severity WHEN 'Critical' THEN 24 WHEN 'Major' THEN 72 ELSE 168 END)
        / NULLIF(COUNT(*), 0), 1) AS sla_breach_pct
    FROM filtered_all WHERE status IN ('Resolved', 'Verified')
    GROUP BY severity
    ORDER BY CASE severity WHEN 'Critical' THEN 1 WHEN 'Major' THEN 2 ELSE 3 END
  ) t) AS avg_resolution_and_sla,

  -- Pareto: defect-type counts with a cumulative % (window functions)
  (SELECT json_agg(t) FROM (
    SELECT defect_type, COUNT(*) AS defect_count,
      ROUND(100.0 * COUNT(*) / SUM(COUNT(*)) OVER (), 1) AS pct_of_total,
      ROUND(SUM(COUNT(*)) OVER (ORDER BY COUNT(*) DESC) * 100.0
            / SUM(COUNT(*)) OVER (), 1) AS cumulative_pct
    FROM filtered_all GROUP BY defect_type ORDER BY defect_count DESC
  ) t) AS pareto,

  -- daily trend
  (SELECT json_agg(t) FROM (
    SELECT date, COUNT(*) AS defect_count
    FROM filtered_all GROUP BY date ORDER BY date
  ) t) AS trend,

  -- disposition breakdown
  (SELECT json_agg(t) FROM (
    SELECT disposition, COUNT(*) AS defect_count, ROUND(SUM(cost_impact), 2) AS total_cost
    FROM filtered_all GROUP BY disposition ORDER BY defect_count DESC
  ) t) AS disposition,

  -- severity breakdown
  (SELECT json_agg(t) FROM (
    SELECT severity, COUNT(*) AS defect_count
    FROM filtered_all GROUP BY severity
    ORDER BY CASE severity WHEN 'Critical' THEN 1 WHEN 'Major' THEN 2 ELSE 3 END
  ) t) AS severity,

  -- root-cause breakdown
  (SELECT json_agg(t) FROM (
    SELECT root_cause, COUNT(*) AS defect_count
    FROM filtered_all GROUP BY root_cause ORDER BY defect_count DESC
  ) t) AS root_cause,

  -- status funnel, ordered by workflow stage
  (SELECT json_agg(t) FROM (
    SELECT status, COUNT(*) AS defect_count
    FROM filtered_all GROUP BY status
    ORDER BY CASE status WHEN 'Detected' THEN 1 WHEN 'RCA' THEN 2 WHEN 'Corrective Action' THEN 3
      WHEN 'Resolved' THEN 4 WHEN 'Verified' THEN 5 END
  ) t) AS status_funnel,

  -- most recent 20 defects, for the live ticker
  (SELECT json_agg(t) FROM (
    SELECT defect_id, date, line, station, defect_type, severity, status, cost_impact
    FROM filtered_line_and_shift ORDER BY defect_id DESC LIMIT 20
  ) t) AS ticker;

With the query written, wire it up so it runs on a timer and its result reaches every widget.

1. Add a change node before the Query node and name it "Set Params". This maps the saved filters onto the $line, $shift, and $daysback parameters the SQL reads. Set four rules, in order:

   • Set queryParameters to {} (JSON): starts clean so stale values don't linger.
   • Set queryParameters.line to filters.line (global persistent).
   • Set queryParameters.shift to filters.shift (global persistent).
   • Set queryParameters.daysback to filters.dateRange (global persistent).

The "Set Params" change node open in the edit panel, all four rules visible.

1. Add an inject node named "Poll Data" and set it to repeat every 10 to 30 seconds. Wire it into "Set Params"; this re-runs the query on a timer so the dashboard keeps up as new defects arrive. Also add a link in node here, named "Refresh Trigger," and connect it to the "Set Params" change node; this will let the filter flow you build next trigger a refresh as well.

2. After the Query node, add a single link out node and name it "KPI Result". Each widget you build next will connect a link in node to it, so the one result broadcasts to every widget at once.

Adding the Filters

The filters go in the dashboard header rather than a widget group, since they control the whole page, not one chart. Each selection saves to the global filters object that "Set Params" reads before every query run.

1. Add a ui-event node. It fires on page load, so a fresh browser session starts with the dropdowns populated.

2. Add a change node named "Set Filters". Set payload to one JSON object containing your filter options. For this tutorial it looks like the following, but update it to match your table:

{
    "line": "SUV Line",
    "shift": "Night",
    "dateRange": 30,
    "lineOptions": [
        "All",
        "Sedan Line",
        "SUV Line",
        "EV Line"
    ],
    "shiftOptions": [
        "All",
        "Morning",
        "Evening",
        "Night"
    ],
    "dateRangeOptions": [
        {
            "label": "Last 7 days",
            "value": 7
        },
        {
            "label": "Last 30 days",
            "value": 30
        },
        {
            "label": "Last 90 days",
            "value": 90
        },
        {
            "label": "All time",
            "value": 100000
        }
    ]
}

3. Add a ui-template node named "Header Filters". Set its type to "Widget" (UI scoped) and select your UI. Ask FlowFuse Expert to build it:

Create a ui-template with three header dropdowns, Line, Shift, and Date Range, wrapped in so they render in the header bar and survive a reload. msg.payload has the selections (line, shift, dateRange) and options (lineOptions, shiftOptions, dateRangeOptions). Line/Shift options are strings; dateRangeOptions items are {label, value} objects, so bind label as text and value as the value, not the whole object. On any change, and on load, send {line, shift, dateRange} downstream.

Below is the template it produced for us, import it directly if you prefer:

The finished header filters. Capture the Line, Shift, and Date Range dropdowns in the live dashboard header.

4. Add a change node named "Save Filters" that sets the persistent global filters to msg.payload, and connect its input to the "Header Filters" ui-template node.

The "Save Filters" change node, setting the persistent global filters to msg.payload.

5. Next, add a link out node, connect its input to the "Save Filters" change node, and connect its output to the "Refresh Trigger" link in node you added earlier.

Deploy, and the dropdowns appear in the header. Change one and the next query pass redraws every widget against it.

Building the Widgets

Everything the dashboard shows comes from the "KPI Result" broadcast, so every widget follows the same wiring: a link in node connected to "KPI Result", a change node that extracts that widget's field, and the display node.

Before adding widgets, create a page for the dashboard (ours is "Assembly Quality Monitor") and a ui-group for each widget. The group is what positions and sizes a widget on the grid.

Stat cards

Start with the four numbers a supervisor checks first: total defects, open, closed, and cost of poor quality.

1. Add a link in node and connect it to "KPI Result".
2. Add a change node named "Extract KPI Summary" with one rule: set msg.payload to msg.payload[0].stat_cards_and_copq (msg). Wire the link in to it.
3. Add four ui-text nodes, one in each of the four top groups (Total Defects, Open, Closed, Cost of Poor Quality). Wire the change node to all four.
4. In each ui-text node, set the value to the matching field: msg.payload[0].total_count, msg.payload[0].open_count, msg.payload[0].closed_count, msg.payload[0].total_copq.

Open counts everything not yet Resolved or Verified; the cost figure sums cost_impact across the current filter, so it moves the moment you switch line or shift.

The four stat cards populated with seeded data.

Pareto chart

The Pareto chart ranks defect types by count and overlays a cumulative-percentage line with an 80% marker. It is the fastest way to see which few defect types cause most of the pain. The built-in ui-chart can't combine bars and a line, so this one is a ui-template that draws the SVG itself.

1. Add a link in node connected to "KPI Result".
2. Add a change node named "Extract Pareto Data": set msg.payload to msg.payload[0].pareto (msg).
3. Add a ui-template node in the Pareto group. Ask FlowFuse Expert to generate it:

Create a Vue ui-template that renders a Pareto chart as responsive inline SVG. msg.payload is an array of {defect_type, defect_count, cumulative_pct}, sorted by count descending. Draw a bar per defect type with its count above and a word-wrapped label below, a cumulative-percentage line with dots over the bars, a dashed threshold line at 80%, and a small legend. Derive the rows from msg.payload reactively so the chart redraws on every new message.

Below is the template it produced for us, import it directly if you prefer:

The rendered Pareto chart. Make sure the cumulative line and the dashed 80% threshold are both visible.

Root cause

1. Add a link in node connected to "KPI Result".
2. Add a change node named "Extract Root Cause Data": set msg.payload to msg.payload[0].root_cause (msg).
3. Add a ui-chart node in the Root Cause group, chart type Bar, root_cause on the x-axis, defect_count on the y.

The query sorts it most-common-first, so the chart reads left to right as a priority list.

The root cause bar chart, bars descending left to right.

Severity and disposition

1. Add two link in nodes connected to "KPI Result", one per chart.
2. Add two change nodes: "Extract Severity Data" sets msg.payload to msg.payload[0].severity; "Extract Disposition Data" sets payload to payload[0].disposition.
3. Add two ui-chart nodes in their groups, chart type Pie. For each, set the label to the category column (severity / disposition) and the value to defect_count.

Severity shows how serious the mix is; disposition shows what it's costing you: Scrap, Rework, or Use-as-is.

The two pie charts. Capture Severity and Disposition together.

Defects per day

1. Add a link in node connected to "KPI Result".
2. Add a change node named "Extract Trend Data": set msg.payload to msg.payload[0].trend (msg).
3. Add a ui-chart node in the Defects Per Day group. Set the chart type to Line, the x-axis property to date (type: time), and the y-axis property to defect_count.

This is where a bad week, or a bad batch, shows up as a bump you can point at.

The daily trend line chart. A date range showing a visible bump makes the point best.

Resolution time and SLA

1. Add a link in node connected to "KPI Result".
2. Add a change node named "Extract Resolution & SLA Data": set msg.payload to msg.payload[0].avg_resolution_and_sla (msg).
3. Add a ui-table node in the Average Resolution group. Turn off auto-columns and configure five: Severity (severity), Hours (avg_resolution_hours), Resolved (resolved_count), SLA Breached (sla_breached_count), SLA % (sla_breach_pct).

This is the widget that answers whether defects are being closed fast enough, not just how many exist.

The resolution/SLA table, all five columns per severity row.

Status funnel

1. Add a link in node connected to "KPI Result".
2. Add a change node named "Extract Status Funnel Data": set payload to payload[0].status_funnel (msg).
3. Add a ui-chart node in the Status Funnel group, chart type Bar, status on the x-axis, defect_count on the y.

The query orders it by workflow stage (Detected, RCA, Corrective Action, Resolved, Verified), so a pile-up at any stage is visible at a glance.

The status funnel bar chart, bars in workflow order.

Deploy and open the dashboard. Every widget populates from the seeded data at once. Change a filter in the header and the whole page recalculates together; leave the live feed running and the numbers keep ticking.

What Next

You've built a working quality dashboard: a defects table, a single query that computes every KPI in one pass, and a page of stat cards, a Pareto chart, trend and breakdown charts, an SLA table, and a status funnel, all filtering live by line, shift, and date.

Right now it runs on the simulator, but that was only ever a stand-in for your real data. To go live, remove the simulator flow and point the query at your own defects table. Everything downstream keeps working, because the dashboard only ever reads from that one query. Your defects don't live in PostgreSQL? That's fine too. FlowFuse connects to MySQL, MongoDB, InfluxDB, and more, as our database integration guides show.

That's the real point. FlowFuse lets you build the exact application your floor needs quickly, without deep engineering knowledge or writing code, wired to the systems you already run instead of forcing your process to fit a fixed tool. This tutorial happened to build defect tracking, but the same approach covers production monitoring, OEE, and the wider quality picture. See how manufacturers are already putting it to work on our automotive solutions page.