Skip to content
shadcn.io

shadcn.io is not affiliated with official shadcn/ui

Monitoring blocks

Pro

dbt Run History Monitoring Block for React Aria

The data tests of one analytics build by model: a select of the last five runs, a list of six models, a filter for warnings and errors, and for a chosen test its compiled SQL with Copy SQL and three failing rows.

Framework
UI library

Preview

Preview width

Installation

Part of Pro
Pro unlocks the code and one-line install of every Pro button and text effect, plus the MCP for your AI editor.
Get ProSign in
Have Pro already? Sign in to open it.Opens here as soon as you're Pro.

Overview

Show which data tests failed in the last build, and why, with this dbt run history for React with React Aria. It is Modelgrove, a run tracker for analytics engineering that reads dbt test results. A Native Select in the header picks one of the last five runs, and the header sentence is counted from the typed results ("21 tests: 5 warnings and 2 errors in 4 models."). A hairline frame with a plus mark on each corner holds a list of six models (name in mono, how many of its tests did not pass) and, for the chosen model, its tests as rows with a mark, a severity and a result. A filter, All, Warnings or Errors, narrows the rows without moving anything. Choosing a test shows its compiled SQL in mono with Copy SQL, which writes to the real clipboard, and, when it failed, three of its failing rows in a small table. The SQL is built from the test's kind (unique, not null, accepted values, relationships, recency) and column. Guides draw the frame and its bands. For analytics teams, data-quality reviews and anyone triaging a red run.

FAQ

How do I load my own test results?

Edit TEST_LINES: one line per test with its model, name, severity (warn or error), kind, column, an example offending value and how many rows fail when it fails. RUNS lists, per run, the names of the tests that failed. A test that fails as a warning counts as a warning, one that fails as an error counts as an error. In your app map the results of dbt test (its run results file) to the same two shapes.

Where does the compiled SQL come from?

sqlLines builds it from the test's kind and column, so it is an illustration, not the query dbt compiled. In your app read the compiled SQL from your artifacts and show it in the same pre.

What stays local, and what is real?

The results are typed examples; nothing is compiled, run or queried. Copy SQL is real: it writes the SQL to the clipboard and says so in the status line, or says that copying is not available.

What does the filter do to the layout?

It only changes which test rows are shown. The tests area keeps a fixed height, so the SQL and the failing rows below it stay where they are, and a model with nothing to show says so in a line.

How does it look on a phone?

The list of models becomes a Native Select above the tests, the filter chips wrap under the heading, and the SQL scrolls sideways inside its box. The failing rows table stays three rows high.

All 100 monitoring blocks