Imagine a bacon-wrapped Ferrari. Still not better than our free technical reports.

RebelLabs reviews Bautablink: a bright tool that makes build failures electrifyingly obvious


Not long ago, a couple RebelLabs technicians, Juri Timošin and Oleg Šelajev, got their hands on a peculiar, rectangular light device by Bautablink.

The background of the story is actually very simple: one day, the gloriously-named Hooman Ostovar contacted us with an idea of getting RebelLabs to test out their new eXtreme Feedback Device (XFD), which gives you immediate visual feedback about what’s happening in your Jenkins Continuous Integration system or in the entire infrastructure monitored by Nagios.

Before we took the bait however, we asked Hooman the critical question: What value does it really bring to developers?

It helps developers make better quality software by making it glaringly obvious when builds or tests are failing. Being an extreme feedback device, it manages to cut through the e-mail noise and make developers and/or operations aware of problems right away. It also makes the state of systems accessible and understandable to business people outside of the development/operations teams. Peer pressure also helps – when that light is red people start talking about it, and just ignoring it tends not to be an option.

Continue reading to see what one can do with the Bautablink device and how to configure this interesting piece of technology to be useful for the team.

A visual review of the tool in question…

Screenshot 2014-04-24 19.17.40

The Bautablink device is 13.3 inch wide, measured precisely by a Macbook Pro, and about as thick as The C++ Programming Language book by Bjarne Stroustrup. So it is not a massive thing, but still takes some space on your table. And if you want to hang it on a wall, you’ll need something  trickier than double-sided tape. Here’s an image of the device, with a mouse included for size comparison.

As you can see, it contains about 75 led lights, which hints that we will be able to configure it to show the results of at least the most important jobs in Jenkins simultaneously. The construction is unapologetically plastic, which it has all the rights to be, and leaves you wondering whether you’ll find an embedded Raspberry Pi on board. Sure enough, Hooman told us that the Bautablink itself is based on a Raspberry Pi, running Raspbian Linux and Python-based software. The Jenkins plugin is, naturally, Java.

We asked Hooman “How did you come up with this idea?”

The idea for Bautablink came out of frustration with running Jenkins and Nagios within a DevOps team and finding out that our Continuous Integration and monitoring tools could have “red alert” states for hours and days without being corrected, even though the team members all agree on fixing those issues should always be top priority.

Starting this notification kit is as easy as following these 3-steps:

  1. Attach the network cable and the power cord
  2. Wait until flickering finishes, which specifies that boot sequence is done
  3. Check that http://bautablink.local:5000/ responds to you.

There’s a way to make it work with a wireless network, which involves writing a two-line configuration file to an USB and rebooting, but we had more interesting investigations ahead of us. Besides, the device still needs power (at least one cable will already be hanging out of it), so we decided to avoid the configuration of the wireless access.

Instead, the manual says that if you want, you can have a direct ssh access to the machine running within the Bautablink. Naturally that was the first thing we did.

> ssh pi@bautablink.local

Here’s an output of the several essential command we like to run when getting into an unknown machine.

 > pi@bautablink ~ $ uname -a
Linux bautablink 3.6.11+ #538 PREEMPT Fri Aug 30 20:42:08 BST 2013 armv6l GNU/Linux

> pi@bautablink ~ $ sudo visudo
visudo: /etc/sudoers.tmp unchanged #pi had a sudo access with no password

> pi@bautablink ~ $ ps uax
root      2060  0.1  1.2  10824  5444 ?        S    13:10   0:02 /usr/bin/python /bauta/bin/ -d -p /var/run/ -l /var/log/bautaconf.log
root      2107  1.0  2.0  22596  9192 ?        Sl   13:10   0:27 /usr/bin/python /bauta/api/ -r -d -p /var/run/
root      2221  0.0  0.2  11548  1072 ?        Ss   13:10   0:00 nginx: master process /usr/sbin/nginx
www-data  2223  0.0  0.3  11708  1696 ?        S    13:10   0:00 nginx: worker process

The process list looks normal, and suggests that the Bautalink software is written in Python. A quick glance into the file gives us some understanding of what’s happening. The whole integration seems simple enough, functions like: blink(color, time), make us wonder how easy would it be to hack the code to make it blink at us for Twitter notifications. Bautablink also hosts a web-server, with a simple application that gives you access to the lights.

Screenshot 2014-04-24 19.33.52

You can play with LEDs even without Jenkins or Nagios. After the initial setup, you connect to a special http address, where you can switch on and off different led lights. Three colors give us 7 + 1 combinations, which is pretty powerful. Let’s make some use of it and connect to our Jenkins instance.

Trial and failure

Bautablink does not pull the information from Jenkins by itself, however the Jenkins master pushes information to the device. This push notification technique is not the way we would actually like it to work; our Jenkins Cluster subnetwork is configured so that it does not see other subnetworks, but instead is visible by them. Thus our first attempt to install it in one of the offices has failed, because it’s network was unreachable from Jenkins.

So, the device must be on the network visible to the Jenkins master, which makes more things more interesting, but more complex topologies suffer.

The Green Hornet’s dream

Naturally a vanilla Jenkins knows nothing about Bautablink and to be able to make the lights flick it has to have a Bautablink plugin installed.

Fortunately, the Jenkins plugin does not need much effort in installation and configuration. All you have to do is download the hpi file and put it into plugins directory inside JENKINS_HOME. Then, after you restart Jenkins, the plugin will be recognized and you will be able to configure it. Go to Manage Jenkins => Configure System and find a section of the Bautablink plugin. There you will have to specify an URL of the device.

The manual states that providing a URL is not required because the plugin is capable of finding the device on its own, but we feel more confident with the URL provided.

Screenshot 2014-04-24 19.36.31

As soon as the connection between Jenkins and Bautablink is established, the device will turn on its LED lights of the specified color, depending on job states. Blue denotes everything is good, yellow/light green indicates that there are some unstable jobs, and red lights mean some jobs are failing. Hooman remarked:

With Bautablink hooked up to Jenkins, there’s no excuse. The feedback loop is as tight as it can be. We don’t let stuff linger. When problems arise, we analyze, test and fix them right away. Then continue with new features and enhancements – with confidence.

If you have some jobs that are not stable enough or often oscillate between the unstable or failed states, then your Bautablink will shine yellow or red most of the time. As seeing the red light is not very helpful (or healthy, actually), there is an option to exclude some jobs from pushing notifications to the device. From here you can either ignore the job completely or ignore just its unstable states.

This is a last resort option, because it greatly undermines the main utility function of the device, but if you cannot do better and fix the build, then it is definitely a workaround. We didn’t find a way to configure the LEDs to flash individually and a brief glance at the wires connecting them suggests that it is not possible with the current configuration.

However, our instance of the Bautablink XFD is connected to the Jenkins instance and cheerfully stares at us with its red look, saying that not everything is 100% flawless among our 3000 Jenkins jobs–and here is where it’s usability, at least for our Jenkins cluster, is limited.

Concluding remarks

We asked Hooman: How do you plan on growing as a company in the future?

We are in the early stages of a beta test phase where some organizations will put it to use in real production environments and hopefully provide insightful feedback. After that we’ll make adjustments based on the feedback and produce a second, larger batch. We intend to take orders online as soon as the beta phase is done and the second batch is in production. Meanwhile (and in the future) we’ll try to build an open source community around the software (plugins for other CI and monitoring systems etc). We want this to be a plug-and-play solution both hardware and software-wise. Eventually we might expand the concept and apply it to other industries with similar monitoring needs.

We are careful to note that this is an alpha version of the product and it is already interesting to play with, usable and useful. There are some minor annoyances with it, but they don’t undermine the main value of the device: instead of emails, SMS or quiet pop-ups, get a real device to laser-bream some ugly lights into your eyeballs when your Continuous Integration server finds anything wrong with your products. So here’s a useful summary of our feelings about the Bautablink feedback device.


  • Good size, easy to spot
  • Nice annoying red light (failed jobs)
  • Calm relaxing blue light (all good)
  • Straightforward configuration
  • Extremely hackable
  • Cable network and wifi support


  • Somewhat massive
  • Doesn’t pull information
  • network topologies can be problem
  • No individual LED control

At this point in Bautablink’s evolution, it’s likely that we would be able to set it up to only notify us about job failures in Jenkins. It is somewhat of a shame to acknowledge, but among our thousands of Jenkins jobs, we do have some random ones of lesser value that are bound to play “street lights” with us. And that means that we’ll always see some red lights in our room.

However, we will put the device to work on medium responsibility monitoring issues. The most important notifications come to phones already, but something like monitoring the Jenkins cluster for load, network access and disk space is not covered with a real world action yet. The Bautablink will allow our admins to close that Nagios tab and rely on the visual signals to spot the upcoming disasters.

Check out more interesting reviews of tools and technologies on our All Reports page. From App Servers and Java Web Frameworks to Static Code Analyzers and IDEs, we got what you need: