Dashboard everything

Across all application teams, but particularly those who are trying to embrace DevOps principles, dashboard technology has an important role to play. Dashboards are key enablers for collaboration within and across teams, and they are excellent at driving the application team in the right direction. They can be the boost that your team needs to get to the next level in your DevOps journey.

Just some ways that dashboards can help your team:

  • Automating the collection and display of data means that we cannot become subjective in our successes and failures, as there is no way to hide from the numbers. It is difficult to argue with raw data, especially when it is unambiguous and displayed for all to see.
  • A well-designed dashboard can help to determine the success level of a release, which ensures that it is in everybody’s interest to have successful releases which provide business value.
  • Dashboard technology can help the team culture move to where you want it to be by highlighting things which may be being overlooked at the moment.
  • They unify the goals of all team members (dev/test/ops etc), and starts/keeps them working in the same direction.
  • Once the data collection is automated, more accurate, reliable measurements means problems are more transparent, people can see them and talk about them with no blame.
  • When things get better, then the material and hard facts are available to publicise and evidence the progress that has been made.

The best way to start if you are unsure what to display, is to dashboard everything: if numbers are available and they can be easily charted, put them on a graph. It will soon become obvious which data is useful and which is not. This will then drive ideas of what to monitor and improve goals. Dashboards need to be evolving so they stay relevant and people continue to look to them to be informed.

Team dashboards are those which are for the whole team (dev/test/ops etc.) and should be application based. The other most common type of dashboard is for ops analytics, which generally display data about the performance of a system or its components and can be low level e.g. CPU usage. I will focus on team dashboards in this post.


In my mind, there are 3 ways to setup team dashboards:


1. Display data which is purely driven from the business goals. This helps to ensure that what is being delivered is in fact what the business needs. These dashboards can keep team members unified and constantly encourages everybody to think about the business value which will be gained from a particular delivery. This can trigger ideas for how to achieve more business value even outside of project scope. The dashboards can also drive consistent status reporting, to ensure that both ops and dev are reporting on the same data and being rewarded based on the same goals. This prevents both ops and dev highlighting their individual successes and glossing over anything which was less successful.

Example data which can be displayed:

  • Total number of users logged in this month
  • Total number/value of purchases this month
  • How many new users this month
  • Usage of newly released services – are they actually bringing in revenue?


2. Display data to solve/address particular challenges that the team is facing right now. These will all be related to business goals underneath, but it may be that highlighting these issues specifically can help people to focus on resolving these issues as a priority.

Example issues which can be highlighted by displaying specific data:

  • If there are too many concurrent releases and the team is struggling to manage them, then display the difference in what version is released to test vs prod and don’t allow that difference to get past a certain number
  • Too many users who sign up to the service then never return
  • If there are slow response times which nobody wants to take responsibility for
  • The current status of builds and if they are broken – to prevent broken deployments
  • Can be used for identifying progress in resolving a critical issue eg a security patch that needs to be rolled out across all services


3. Display information about what team members are doing. If people are more aware of what is happening then credibility will be built up and this can help to build better relationships across teams. Also this gives people the opportunity to proactively identify changes and improvements they wish to make as they will be aware of what is going on in the wider team.

Example data which can be displayed:

  • Current status of ongoing projects ad who is working on them
  • Current status of bug fixes
  • Any improvement initiatives which are underway


In many ways, the 2nd type of dashboard can be most useful to start with, particularly if you are on a DevOps journey and still in the transition state. It can help galvanise the team and importantly, help to change the culture, or at the very least assist the cultural changes to be embedded.

The following two tabs change content below.

Bronwyn Davies

Bronwyn Davies is a senior DevOps consultant at Sandhata Technologies. She brings more than 12 years' experience in application development to help clients achieve their DevOps ambitions. With in-depth understanding of the financial industry, she is able to draw on her experiences and knowledge to provide best practise guidance and practical tips to organisations looking to reinvent their application development processes.

Latest posts by Bronwyn Davies (see all)