When I posted the first dashboard after the SolarWinds World Tour, I did not originally plan for it to become a full series.
It started as a bit of fun: a chance to showcase how far the SolarWinds dashboard layer could be pushed beyond the standard widgets.
But as the series developed, a clearer theme started to emerge.
The visuals were only part of the story.
The real focus became how monitoring evidence can be turned into something easier to understand, trust, and act on.
The series so far
Part 1: SolarWinds World Tour Dashboard - Pushing Dashboards Beyond the Default
The aim was simple: move beyond the usual tables, charts, and gauges, and explore what could be created directly inside SolarWinds using SQL-generated HTML, CSS, and inline SVG.
It showed that a SolarWinds dashboard does not have to feel static or purely functional.
There is room for movement, depth, visual hierarchy, and a stronger operational story.
Part 2: Observability Lens - A Glass View into the Evidence Layer
Part 2 moved away from visual experimentation and into monitoring trust.
The Observability Lens focused on the evidence layer itself.
A critical object and an unknown object are not the same thing.
One is evidence of failure.
The other is a gap in confidence.
That distinction became one of the most important themes across the whole series:
Evidence
→ Confidence
→ State
Before interpreting a service, the monitoring evidence has to be trusted.
Part 3: Alert Pressure Skyline - Turning Alert Behaviour into Operational Posture
Part 3 looked at alerts differently.
Instead of treating every trigger as an isolated event, the Alert Pressure Skyline used alert activity, recurrence, age, and volume to show wider operational pressure.
The lesson was simple:
Alert volume
≠
Operational understanding
A long list of alerts tells you what fired.
It does not always tell you what matters most.
The aim was to turn alert behaviour into posture.
Part 4: Platform Observability Reactor - Monitoring the Monitoring
Part 4 turned the lens back onto SolarWinds itself.
If the monitoring platform is responsible for reporting the health of the estate, it also needs to expose its own health, freshness, load, and confidence.
That became the Platform Observability Reactor.
The key question was:
Can the monitoring platform currently be trusted to tell the truth?
That is an important part of observability that can easily be overlooked.
Part 5: Vector Engine - Resolving Live Evidence into Service Posture
Part 5 brought the earlier ideas together.
The Vector Engine takes multiple live evidence domains and resolves them into a single service posture.
For the Database example, that includes:
- Infrastructure
- Applications
- Storage
- Network Pressure
- Alert Pressure
- Coverage
Each evidence pathway contributes differently.
A warning does not automatically force the whole service into a critical state.
A monitoring-authentication issue is not interpreted in the same way as a stopped database service.
A storage-capacity warning is visible, but it does not overstate the wider service impact.
The wider pattern is:
Evidence
→ Domain State
→ Service Posture
→ Problems / Advisory
→ Action
The aim is not to show more information.
The aim is to make the operational story easier to recognise.
What the series has shown
Across the six posts, a few themes kept returning.
Dashboards should lead with posture
The first question should not be:
How many metrics can fit on the screen?
It should be:
What does the operator need to understand first?
A strong dashboard leads with the clearest signal and uses supporting evidence to explain it.
Evidence and state should remain separate
Evidence is what has happened.
State is the interpretation of that evidence.
Keeping those layers separate makes it easier to reduce noise, explain decisions, and avoid turning every individual signal into an incident.
Unknown is not healthy
Missing data, stale polling, muted entities, and incomplete coverage should remain visible.
A green dashboard with weak evidence is not a healthy dashboard.
It is a dashboard with misplaced confidence.
Alerts are evidence, not always incidents
Not every alert should generate a ticket.
Repeated alerts, trends, and recurring patterns can act as advisory signals before they become operational problems.
That separation helps reduce noise and makes the incident layer more meaningful.
Visual design can support operational clarity
Animation, colour, movement, and depth are useful when they represent something real:
- evidence flow
- state
- pressure
- recurrence
- confidence
- risk
- action
The strongest visuals are not decorative.
They make the signal easier to understand.
Looking back
I have now been working with SolarWinds for close to 15 years.
Over that time, I have built and contributed to monitoring and observability platforms across a wide range of enterprise environments, worked alongside some brilliant people, and seen the platform evolve significantly.
I also had the opportunity to host not one, but two SolarWinds User Group events and made friends for life :)
More recently, attending the SolarWinds World Tour brought some of that journey full circle.
It is strange to think this started with a World Tour dashboard and ended up here
One thing I can say for sure:
The tools have changed.
The dashboard layer has changed.
The way we think about monitoring has changed.
But the core problem is still familiar:
How do we turn large amounts of technical evidence into something people can understand and act on quickly?
That is what this series has really been about.
Closing the loop
The dashboards have been great fun
But the most interesting part has been the thinking underneath them.
The series started with visuals.
It ended with a model:
Evidence
→ State
→ Problems / Advisory
→ Action
For me, that is the difference between displaying data and telling an operational story.
Thank you to everyone who followed the series, commented, shared feedback, or encouraged me to keep going.
I really appreciate it. ✌️
Previous posts
Part 1: SolarWinds World Tour Dashboard - Pushing Dashboards Beyond the Default
Part 2: Observability Lens - A Glass View into the Evidence Layer
Part 3: Alert Pressure Skyline - Turning Alert Behaviour into Operational Posture
Part 4: Platform Observability Reactor - Monitoring the Monitoring
Part 5: Vector Engine - Resolving Live Evidence into Service Posture
A special thanks to @vinay.by and @naveensingh43 for always giving positive and encouraging feedback
P.S. If you ever need another MVP, please vote for your Egg 😄
