build-monitor-plugin and the case for putting CI status on the wall

A view type, not a page you add to a dashboard

The Build Monitor plugin provides a highly visible view of the status of selected Jenkins jobs, and the way it is used is stated plainly: it easily accommodates different computer screen sizes and is ideal as an Extreme Feedback Device to be displayed on a screen on your office wall.

That phrase, Extreme Feedback Device, is the design brief in full. The plugin is not competing with the Jenkins dashboard or with a wallboard you build from the REST API. It is a screen that people glance at from across a room, and it optimises for that at the expense of everything else.

The mechanism is a view type. To create a new Build Monitor View, you click on the New View tab, select Build Monitor View and choose the jobs you want displayed on the monitor. You can have as many Build Monitor Views as you want, and the most popular approach is one per team or one per project.

So the unit of configuration is a Jenkins view containing a chosen set of jobs, rendered full screen. That is why the plugin can be simultaneously trivial to set up and limited in what it shows: there is no query, no filter language and no chart, just a curated list of jobs and a large rendering of each one's state.

The default refresh is four seconds, and it is configurable

The first item in the feature list is the mechanism that keeps the display current: it displays the status and progress of selected jobs, and by default the view refreshes every four seconds. This can be configured.

Four seconds is a meaningful number for a wall display. It is fast enough that a person walking past sees a state that is at most a few seconds old, and slow enough that a room full of screens does not turn into a request storm against the Jenkins controller. A build that fails appears on the wall within about four seconds of the controller knowing about it.

The progress part matters as much as the status. A build that is running shows progress, so a screen that has been red for two minutes can be distinguished from a screen that has just gone red, and a team can see at a glance whether anything is happening at all. On a wall display, that difference is the difference between a person walking over to a colleague and a person going back to their desk.

Because the interval is configurable, the same view type can be tuned for a wall in an open-plan office or for a screen in a room where a four-second refresh would be distracting. There is also a documented way to check the wiring, since the guide links three screenshots under docs/, one for adding jobs, one showing a three column view and one showing colour-blind mode.

The plugin composes: claiming, filtering and failure analysis come from elsewhere

Most of the useful features in this plugin are integrations with other Jenkins plugins, and that is the single most important structural fact about it.

The list is explicit. It supports the Claim plugin, so you can see who is fixing a broken build. It supports View Job Filters, so you can easily create Build Monitors for slow builds or only failing ones. It supports Build Failure Analyzer, so you know not only who but also what broke the build. It supports the Folder plugin, so you can have project and team specific nested Build Monitors. It supports the Pipeline plugin, so the currently executing stages are shown. It supports the Theme Manager plugin, so you can switch between themes, and the Customizable Header plugin, so your team can have a custom header.

The FAQ shows how the composition works in practice. To let teammates know you are fixing a broken build, you claim it, and Build Monitor picks that up once you have the Claim plugin installed and have enabled Broken build claiming in the Post-build actions of your Jenkins job. The guide also links a script that enables claiming on all your Jenkins jobs at once, which tells you that the per-job configuration step is the friction point people hit.

For failure analysis the guide is characteristically direct: get the Build Failure Analyzer plugin, teach it, and Build Monitor will tell you what the analyzer found. The plugin does not parse test results itself. It renders what other plugins know, which is both its strength and its dependency risk.

Screens are sized with columns and font size, not with a theme

The layout controls are simple and they exist for a physical reason.

The number of columns and the size of the font used are easily customisable, which the guide says makes it trivial to accommodate screens of different sizes. The UI is configurable so you can have a different number of columns and use a different font size on each of the screens in your office. That is an unusual degree of per-screen control, and it only makes sense if the plugin is expected to run on several different displays, some large and some small, each read from a different distance.

The other display-related feature is a color-blind-friendly mode, and the guide includes a screenshot of it under docs/colour-blind-mode.png, which suggests it is treated as a first-class option rather than an afterthought. On a wall display in a shared office, a red and green status pair that is unreadable for one person in eight is a real problem, and the mode is the answer to it.

The Pipeline plugin integration deserves a second mention because it changes what a row shows. Without it a row is a job name and a state. With it, the currently executing stage is shown, so a long multi-stage pipeline shows where it is rather than only that it is running. On a wall, that is the difference between a red row and a row that says which stage went red.

The frontend was rebuilt on Vite and React, and it shows

The build files describe a modern JavaScript toolchain grafted onto a Java plugin, and they explain a lot about the project's direction.

The package.json for the plugin's frontend is private, typed as module, and declares react 19.3.1 and react-dom 19.3.1 with @tippyjs/react for tooltips. The build is vite build --mode production, the test script is vitest run, and the lint script runs prettier and eslint over src/main/frontend/. The devDependencies show the full modern set, including jsdom and @testing-library/react for component tests, sass-embedded for styles, and eslint-formatter-checkstyle, which is there to emit checkstyle reports that the Jenkins CI can consume. The engines field requires Node 22 or newer.

The Java side is still a Maven project, with pom.xml at the root, and the package scripts bridge the two: mvnbuild runs the npm build and mvntest runs the npm test. A Jenkinsfile at the root drives the pipeline, and the .mvn directory plus .mvn_exec_node show the Maven wrapper setup, so the build is reproducible from a clean checkout without a system Node or Maven of a particular version.

What this tells you is that the plugin's user interface is now a React application compiled by Vite, embedded into a Jenkins plugin. That is a large shift for a display plugin that once was server-rendered Java, and it explains the presence of vite.config.ts, vitest.config.ts, tsconfig.json and an eslint config alongside the Java tree.

Getting started: install it, then create one view per team

Installation is the ordinary Jenkins plugin route, through the plugin page on plugins.jenkins.io, and the guide's getting started section is short enough to quote in full as a procedure.

Click on the New View tab, select Build Monitor View, and select the jobs you wish to display on the monitor. The guide calls that simple, and it is: there is no configuration file, no XML to hand-edit and no property to set. What you get is a view that renders full screen with those jobs, and you can have as many of those views as you want.

The sensible starting point is one view per team or one per project, which is what the guide says the most popular approach is. Splitting by team means each group of people sees the jobs they are responsible for, and splitting by project means the same jobs can appear on two screens with different groupings.

The one configuration you should think about up front is the refresh interval, because the default of four seconds is tuned for a wall display. If the screen is on a desk where a four-second update is distracting, lower it before you roll it out.

For anyone working on the plugin itself, the build commands live in the frontend package.json, where the scripts bridge the Java and JavaScript halves:

    "mvnbuild": "npm run build",
    "mvntest": "npm run test",
    "build": "vite build --mode production",
    "test": "vitest run"

So a frontend change is compiled with vite and checked with vitest, and the two npm scripts wrap those calls for the Maven build to invoke.

Too many jobs on one screen is the failure mode the FAQ addresses

The FAQ contains the most useful criticism of the plugin, and it is written from experience rather than as a feature list.

Asked what to do with too many jobs on one screen, it offers three options. First, review the granularity of your jobs: if you have too many low-level jobs displayed on one screen, consider consolidating them using the Promoted Builds plugin or the MultiJob plugin. Second, use job filters, which Build Monitor supports if you have the View Job Filters plugin installed. Third, get a bigger screen.

That ordering is a design position worth taking seriously. The first suggestion is to change what you are displaying rather than how you are displaying it, and it points at a genuinely different approach: the Promoted Builds plugin lets a build be marked as important so the monitor shows meaningful jobs only, and MultiJob groups several jobs into one logical entry. Job filters are the plugin's own answer, letting a monitor be defined as slow builds or only failing rather than everything.

The third option, a bigger screen, is honest about the fact that a wall display has finite area. It also explains why the column and font size controls exist, and why a per-screen configuration is a feature rather than a nicety.

Release naming, licences and the maintenance signal

The versioning tells you this is a plugin that follows the Jenkins incrementing release convention rather than semantic versioning.

The recent releases are 1131.va_2d8e68fc912 from 2026-09-12, 1116.v4d2f13e3a_a_a_6 from 2026-08-13 and 1113.v841eb_e2ccda_5 from 2026-08-05. The numeric prefix counts releases, and the suffix is derived from the commit, which is how Jenkins plugins avoid version collisions with forks and local builds. There is no major version, no minor version and nothing in the name that tells you whether a change breaks your configuration.

That makes the upgrade story procedural rather than semantic. You read the CHANGELOG.md at the root to find out what changed, because the tag itself will not tell you.

The licence is MIT, the repository is not archived, and the last push was on 2026-10-19. The plugin page is on plugins.jenkins.io, and the guide closes by saying the plugin is continuously delivered to a Jenkins near you thanks to the time and commitment of the author and the contributors, with a link to the Gitter channel for the Jenkins user experience group.

Feedback goes through GitHub issues and pull requests, with a link to a development guide wiki page for new contributors, and a .git-blame-ignore-revs file in the root for the same formatting-history reason.

Editorial conclusion

build-monitor-plugin suits a team that wants a shared, glanceable signal about which build is red and who owns it, mounted on a wall display, because that is the narrow job it does well and the aggressive visual design serves exactly that. It does not suit anyone who wants a dashboard to explore, since a Build Monitor View is a fixed list of jobs with no drill-down, and it does not suit a deployment that needs the claiming, filtering or failure analysis features, because those come from separate plugins you have to install and configure. Before rolling it out, check the plugin list, note that the refresh interval defaults to four seconds, and remember the last push was on 2026-10-19 with release 1131.va_2d8e68fc912 published on 2026-09-12.

Frequently asked questions

Official sources

1. jenkinsci/build-monitor-plugin on GitHub
2. License: MIT
3. Project website
4. README
5. Releases