[Improvement] Global Aggregated Dashboard for Multi-Project Monitoring

[calado-merkle]

First of all, congratulations to everyone involved in the development of RobotDashboard.
After testing the new version extensively, I am genuinely impressed with the overall quality and completeness of the solution.
The solution is very well designed and will be adopted in our projects going forward.

At the moment, we are running a setup where a central server initializes independent RobotDashboard instances per project. This allows us to maintain isolated dashboards, each customized according to the specific requirements of the respective project.

We would like to suggest the introduction of an additional higher-level dashboard layer capable of aggregating information from multiple active project dashboards/servers.

The idea would be to provide:

• A centralized management dashboard
• Cross-project KPI visualization
• Aggregated metrics and reporting
• Consolidated tables/data from all monitored projects
• High-level visibility without needing to access each individual project dashboard separately

Examples of useful aggregated information:

• Overall execution status across projects
• Pass/fail trends
• Execution duration metrics
• Environment health/status
• Unified reporting views
• Custom organizational KPIs

Although this may extend beyond the original scope of RobotDashboard, it would provide significant value from a management and operational perspective, especially for organizations managing multiple independent projects.
This would greatly simplify monitoring activities and improve visibility at a portfolio/program level.

Once again, congratulations for the excellent work and for building such a flexible and extensible solution.

[timdegroot1996]

@calado-merkle thanks for the comment regarding the quality! We do our best and its nice to hear that it shows!

Regarding your suggestion, I understand what you are going for. It is indeed kind of a special scenario which doesn't directly fit into robotdashboard. HOWEVER I think its cool to have something like this 😄. So I might try to implement something like this as an additional package or option anyway.

Some design decisions that pop up right away:

• What would be a good name for this higher level dashboard? All good things start with a name right 😉, my AI gave this list, which ones do you like?

Clear / Enterprise-style
These communicate hierarchy and aggregation directly:

RobotDashboard Hub

RobotDashboard Central

RobotDashboard Overview

RobotDashboard Global

RobotDashboard Federation

RobotDashboard Unified

RobotDashboard Command Center

RobotDashboard Portfolio

RobotDashboard Control Plane

RobotDashboard Observatory

DevOps / Platform-oriented
Good if the tool is used by engineering orgs with many teams/projects:

RobotDashboard Fleet

RobotDashboard Nexus

RobotDashboard Matrix

RobotDashboard Atlas

RobotDashboard Mission Control

RobotDashboard Grid

RobotDashboard Pulse

RobotDashboard Beacon

RobotDashboard Aggregate

RobotDashboard Panorama

Hierarchical naming
If you want the relationship to be very obvious:

RobotDashboard Parent

RobotDashboard Meta

RobotDashboard MetaView

RobotDashboard SuperDashboard

RobotDashboard Executive

RobotDashboard Enterprise

RobotDashboard Global View

RobotDashboard MultiView

RobotDashboard Cluster

RobotDashboard Network

Modern SaaS-style
More product/brand flavored:

RoboScope

RoboVista

RoboAtlas

RoboPulse

RoboWatch

RoboOps Center

TestSphere

TestAtlas

TestOrbit

TestFederation

• You describe it as something like an alternative server version which can be hosted. I like that idea but I think I would also like to have a regular option available so non server users can use this feature.
• This brings me to the data question, how should we feed the data into the global dashboard? For the server a specific endpoint could be good, but then these should somehow be configured on startup. For local use I think just using a list of databases is the simplest implementation since we can then create some database functions to retrieve the data we would like to show. (Server endpoint can then also use this same logic to provide the data if requested by the global server).
• Then the last thing that is quite important is what we want to show. You already give quite a clear outline of the stats or data you want to see, which seems mostly run level data (correct me if Im wrong). But how should this be shown? Im thinking of starting out with a single dashboard page just like how robotdashboard has that tab which is the main focus, and try to huild it from there. However a small mockup or some references to which graphs you think would be good to add would be very helpful!

I will probably think of some other questions later but if you could provide your insights regarding above points that would be very nice!

[calado-merkle]

Hi! Thanks a lot for the detailed and thoughtful reply, really appreciate the engagement around this idea.

I’ll try to address your points one by one:

1. Naming

From your list, the ones I like the most are:

• RobotDashboard Executive
• RobotDashboard Unified
• RobotDashboard Observatory

"Executive" fits really well with the idea of a higher-level management/dashboard view, while "Unified" and "Observatory" also communicate aggregation and visibility quite nicely.

I also thought of a few extra names 😄:

• Captain RobotDashboard
• RobotDashboard Overlord
• RoboCharts & Chill
• RobotDashboard OneView
• RobotDash Aggregator

2. Architecture

Your interpretation is exactly aligned with what I had in mind.
I agree that it makes sense to support both modes:

• Server mode: ingestion via configured endpoints on startup
• Local mode: direct connection via a list of databases

I like the idea of reusing the same internal data retrieval layer for both cases, that would keep things clean and consistent.
The only missing piece would be defining how the aggregator discovers the data sources. A few ideas that could work:

• a simple config file with a list of dashboard/database locations
• environment variables
• a small registration mechanism where individual dashboards announce themselves to the aggregator
• watched directory containing the SQLite files

I think the cleanest and most flexible long-term approach would be a small registration mechanism where individual dashboards can announce themselves to the aggregator.
That would avoid having to manually maintain lists of databases/instances and would also work nicely for dynamic or distributed environments.
A config-file-based approach could still be a great/simple option for local setups or MVP implementations though.

3. Metrics

Yes, your understanding is correct, the initial focus is mostly run-level + execution-level aggregation.
I would suggest structuring it in layers:

High-level overview (landing page):

• Total executions (across all projects)
• Global pass/fail rate
• Trend over time (daily/weekly)
• Active environments / health status

Project comparison view:

• Pass/fail per project
• Execution duration averages per project
• Stability ranking (most/least stable projects)
  Drill-down capability:
• Ability to click into a project and jump into the existing RobotDashboard instance

4. Visualization ideas

For the first iteration, I would keep it relatively simple and focused:

• Line chart: global execution trend over time
• Stacked bar chart: pass/fail per project
• Table: project health overview (status, last run, failure rate, duration)
• Heatmap (optional later): failures by project/time

I agree that starting with a single main dashboard page is the right approach, and then iterating into more detailed views once the core is solid.

Overall I really like the direction you’re proposing, especially the idea of making it usable both as a hosted server and as a local multi-database setup. That flexibility will make it much more broadly applicable.

Happy to continue brainstorming and sharing suggestions/feedback as the idea evolves.

[timdegroot1996]

Thanks for the fast response!

1. Naming

I think I also kind of like "RobotDashboard Hub" and "RobotDashboard Executive". Those are the best ones I might choose from. A for effort on your suggestions though! 😄, especially "RoboCharts & Chill" gave me a good laugh.

2. Architecture

The architecture I was thinking of at the start was for now just an extra CLI argument in which you can provide multiple URL's for the server implementation, or multiple paths to the databases. I think adding a mechanism to update them while running could be good but that's mainly for the server implementation.

For now I think I will at least make 1 & 2, and 3 & 4 could be a nice future addition:

1. --dashboardhub https://url-to-dashboard-1/;https://url-to-dashboard-2/;https://url-to-dashboard-3/;https://url-to-dashboard-4/
2. --dashboardhub path/to/1.db;path/to/2.db;path/to/3.db;path/to/4.db
3. Add an endpoint named POST add-hub, which receives a url. And in the handling it will then update a local (on the server side) it will update a local .json file. Restarts will then automatically detect that json file. In the dashboard hub we can then also provide some view to add endpoints there.
4. The same logic as 3 but for deleting should also be added. And perhaps a small listview in the hub of configured endpoints is also a good nice to have.

3. Metrics

Am I undestanding this correctly that you want a global overview tab (kind of like the overview page already existing in the regular dashboard) which then links to a second tab if you click certain items (or through the menu ofcourse) which let's you zoom in on run details of a specific project with even more graphs/details?

4. Visualization ideas

I get a good idea of what you would like to show and see. Thanks for that.
Regarding 3. I'm kind of curious what you would want to see in the "Overview" tab and in the "Dashboard" tab, since I think adding both of those is very doable.

Overall I really like the direction you’re proposing, especially the idea of making it usable both as a hosted server and as a local multi-database setup. That flexibility will make it much more broadly applicable.

This will also greatly improve testing it as I don't have to host multiple servers 😉, but that could obviously also be done if you just start up a couple different ones.

Happy to continue brainstorming and sharing suggestions/feedback as the idea evolves.

Once I have a decently working version I will probably ask you to install and test it so we can see if it matches your expectations. Or I might just provide static dashboard_hub.html files, we'll be in touch for sure 👍

[timdegroot1996]

@calado-merkle I've already been working on this one for a bit and I think the name I like the most is Robotdashboard Hub. It's quite short and understandable what it means.

As the implementation was ongoing (this branch: https://github.com/MarketSquare/robotframework-dashboard/tree/dashboard-hub) I realized that it would become quite messy with the amount of extra parameters and code that I had to duplicate or modify to enable this in the CLI, the javascript and the css.

Therefore I think I will move this to a separate package named "robotframework-hub" or something similar which can be installed separately and then can be started by robothub instead of robotdashboard --hub .. whatever. This gives a nice way to split the arguments and all logic related to the hub into this service. The only thing I will have to implement in robotdashboard are some endpoints to provide the data that feed into the hub server.

Let me know what you think about all of this and if there's anything that you think could be limiting. Thanks in advance!

[calado-merkle]

Honestly, I think moving this into a separate package is the right architectural decision.

The more the feature evolved from a simple “multi-dashboard mode” into an actual aggregation platform/service, the more it makes sense to keep the responsibilities separated.

Keeping RobotDashboard focused on:

• collecting/storing project-level execution data
• exposing lightweight endpoints

while RobotDashboard Hub becomes responsible for:

• aggregation
• cross-project analytics
• centralized views
• management logic

feels much cleaner and much easier to maintain long-term.

I also think this separation will help a lot with:

• keeping the main RobotDashboard CLI simple
• avoiding conditional logic everywhere in the frontend/backend
• allowing Hub to evolve independently later (authentication, caching, historical aggregation, multi-user support, etc.)

The proposed flow sounds very solid to me:

• RobotDashboard instances expose data endpoints
• Hub consumes and aggregates them
• local DB mode remains available for lightweight/local usage

That gives a very nice balance between simplicity and scalability.

One thing that could be interesting in the future is following a philosophy somewhat similar to Selenium Grid:

• lightweight independent nodes/services
• centralized orchestration/visibility layer
• dynamic registration/discovery
• scalable and loosely coupled architecture

Not necessarily copying Selenium Grid directly of course, but I think the conceptual model fits very well for what you’re building here.

Another thing that I think could become important later (not necessarily for MVP) is introducing some kind of source metadata/configuration layer, for example:

• project name override
• environment tags
• team/department labels
• grouping
• custom KPI tags

That could make the aggregation views much more powerful once people start using many dashboards.

Another thing that I think is very smart in your approach is keeping the initial implementation intentionally small:

• one main dashboard
• a few core metrics
• drill-down links back into project dashboards

That’s probably the perfect MVP because the value already becomes immediately visible without overengineering the first version.

Really excited to see where this goes, I genuinely think this could become a very valuable addition for teams managing multiple automation projects.