The Operations Dashboard is the landing page of CloverDX Server designed to quickly show the state of data processing (typically for a business process). It shows Monitors and their state, where each Monitor watches the state of several items that automate data processing (i.e. Schedules, Event Listeners, Data Services). These items perform the data processing needed by the business process.

Multiple Dashboards can be defined. This is useful in more complex deployments, where each Dashboard could cover a separate project, area of responsibility of a specific team etc. Each of the Dashboards has its own set of Monitors (i.e. a Monitor belongs to just one Dashboard, it cannot be shared). There is one default Dashboard provided by default - Main Dashboard. Name of the currently selected Dashboard is shown in the top-left corner of Operations Dashboard.

Switching between Dashboards is done via the Switch Dashboard widget at the top right. The Switch Dashboard widget provides also actions for Dashboards:

If some Monitors are failing, they are highlighted in red color. With the Show failing first button, it’s possible to switch the dashboard to a visualization mode where the failing Monitors are shown at the top. This is useful with a larger number of Monitors to see all the failing ones at the top.

The dashboard shows all Monitors as tiles, providing the following information:

The three-dot button is used to perform actions on the Monitor:

The Monitors are designed to represent data processing of a business process. They allow you to quickly see the health of the data processing, even though it can be implemented by a wide range of functionality - running jobs from Schedules, triggering them via Event Listeners or using Data Services (or Data Apps). Monitor can be used to guard Schedules, Event Listeners and Data Services from one or more sandboxes.

Monitors watch the health of data processing by watching the state of automations represented by items:

All of the automations that can be watched by a Monitor provide a similar concept of state. They can be configured to report as failing when certain conditions are met (see Alerts and Notification). Typical cases:

The more complex failure configurations are typically used for frequently called automations - for example API implemented by a Data Service would be considered as failing only when 10 calls of the Data Service fail in a row. On the other hand, scheduled run of an important job that performs daily load of data would be considered as failing immediately when the job fails.

If a Monitor starts to fail and then returns to passing state, it stays in a warning state. This feature is designed to prevent missing important failures in the past - for example, there can be outages during the weekend that stop happening and would be missed by support team on Monday. When you select a Monitor in the warning state, you will find warning details in some of its items. To acknowledge that the warning is handled, mark the issue as resolved (see Operations Dashboard - Issue Investigation).

To drill down to details about a failure, select a Monitor in the dashboard to see a list of its items:

You can click on an item to see more of the error message and to see available actions. The Show action (e.g. Show Schedule) will navigate you to the configuration of the affected item - e.g. it will show you the configuration of the affected Schedule. From there you can analyze the issue in more detail, check the configuration of the item, go to the history of executions of the automation etc. The Show history action takes you directly to the history of the item, e.g. to history of executions of the specific Schedule.

The Monitors update their state automatically based on the state of their items. So if an item stops failing because of some intermittent issue (e.g. networking problem), its Monitor will automatically stop being marked as failing.

If a Monitor starts to fail and then returns to passing state, it stays in a warning state. This feature is designed to prevent missing important failures in the past - for example, there can be outages during the weekend that stop happening and would be missed by support team on Monday. When you select a Monitor in the warning state, you will find warning details in some of its items. To acknowledge that the warning is handled, mark the issue as resolved , see below for details.

It is possible to manually reset the health of an item to mark it as successfully passing - use the Mark as resolved action on the item in Operations Dashboard. This is typically used when you fix the underlying issue that caused the failure (e.g. configuration of a system), but the item will run later and you can mark it as already resolved so that someone else will not spend time on the issue. Resolving all failures resolves the failing state of the Monitor. This action is also used to reset the state of a Monitor in warning state, where an item was failing recently but passes currently. In such case the action indicates that the recent outage was analyzed and handled.

You can use the Mark all as resolved action to resolve all issues in a Monitor:

To analyze history of changes to the state of Monitors, use the Monitor Log. It contains detailed historical information on Monitor health, failing and recovering monitored items and manual reset of item health.

Monitors are manually created and the items watched by the Monitors are explicitly selected, i.e. the Monitors are not automatically generated.

Each Monitor belongs to one Dashboard. In case you have multiple Dashboards defined, you create and configure Monitors for the currently selected Dashboard.

Creating a Monitor:

When creating a Monitor, you must specify the items it watches. These items perform the data processing or business process represented by the Monitor. To add an item to a Monitor, drag & drop it from the right side to the left. It’s possible to add all items related to a sandbox by dragging & dropping the sandbox, or to add all items of some type by e.g. dragging the Schedules node.

To change configuration of a Monitor, select it and use the Edit action. The edit action is also available in the three-dot button.

Items are not added automatically to a Monitor. For example if you create a new Schedule that runs a job from a sandbox, then you need to update some Monitor to watch the state of the Schedule.

It is possible to import & export the configuration of the dashboard and all its Monitors via the standard Server Configuration Migration feature of CloverDX Server.