Monitor details
The monitor details page is where you check how a single monitor has been behaving.
It answers whether the last run passed, how reliably the monitor passes over time, what it measured on each run, and how it is configured today. Open it by clicking any monitor on the Monitors tab, or from a case the monitor raised.
The header cards
Three cards run across the top of the page and summarise the monitor's health.
Latest run shows the outcome of the most recent run and when it ran.
Latest case shows the state of the most recent case, how many incidents it holds, and when its first incident was raised.
Pass rate shows the share of evaluated runs that passed, along with how many runs went into that figure. The window is stated on the card, for example Last 7 days, and scales to how often the monitor runs, so a frequent monitor and an infrequent one are both judged over a meaningful number of runs.
Only passed and failed runs count towards the pass rate. Runs that Decube skipped, and runs that errored, are excluded from it and are listed in Run History.
The page header carries the monitor name, the asset it runs against, its monitor type, the source and schema, and a status badge of Active, Inactive, or Invalid.
Monitor performance and history
The body of the page has three tabs.
Performance
Performance charts what the monitor has measured, run by run, over the date range you select.
The chart selector lists the graphs available for this monitor type. The first is selected by default and plots the metric the run outcome is decided on. The others give context around it, such as how many rows were scanned.
Bound line draws the limit each run was judged against, with the passing region shaded. Toggle it off to read the raw shape of the metric.
Out-of-bounds points are marked in red. Each one is a run that breached the limit and raised an incident.
Errored or skipped runs appear as hatched bands, covering the periods where the monitor produced no measurement.
Cases
Cases lists every case this monitor has raised, open and closed. Each case leads you to the case details page where you can view more details on each case.
Run History
Run History gives you a row per run, including the runs that were skipped or errored with their reasons. This is the complete record, where Performance and Pass rate both narrow to runs that produced a measurement.
Viewing an earlier version
The Viewing selector above the tabs switches between versions of the monitor. Selecting an earlier version shows the metrics collected while that configuration was live, alongside the configuration itself.
Versions exist because some configuration changes alter what the monitor measures, which makes the readings taken before and after incomparable. Changing the schedule or the detection method archives the current version and starts a new one, so the earlier history stays attributable to the rules it was collected under. Changing the threshold, the attributes, or the data quality dimension applies in place and leaves the history continuous.
Monitor properties
The right-hand panel holds the monitor's configuration in read-only form.
Monitor status, matching the badge in the header.
Description, the free-text explanation of what this monitor is for.
DQ dimension, the data quality dimension the monitor is classified under, such as Accuracy or Timeliness.
Custom attributes set on the monitor, such as Criticality or SLA Tolerance. Attributes live on the monitor and are read live wherever they surface, including on every incident and case it generates, and alert rules can route on them.
Actions you can take
The Monitor actions menu in the header covers everything you can do to the monitor from this page.
Edit monitor
Opens the modification wizard on the step you want to change. A change that alters what the monitor measures warns you that it creates a new version before it applies.
Enable or Disable
Disabling stops the monitor from running. Its history, cases, and incidents stay in place, and enabling it resumes the schedule.
Run now
Available on monitors set to a manual frequency. The monitor moves into a running state and the page updates when the run finishes.
View all versions
Lists every version of the monitor. Click into one to read the configuration it ran under.
View matching alerts
Shows the alert rules that currently match this monitor, whether by filter or by explicit selection. It is a read-only list, with a Go to Alerts button for managing the rules themselves.
Delete monitor
Removes the monitor and everything attached to it.
Deleting a monitor also deletes its run history, cases, and incidents. Disable the monitor instead when you want to stop it running but keep the record.
Frequently Asked Questions
The latest run passed, so why is the pass rate below 100%?
Pass rate covers a window of runs rather than the most recent one. A monitor that failed twice yesterday and has passed since shows a healthy latest run alongside a lower pass rate, until those failures age out of the window.
Which runs count towards the pass rate?
Passed and failed runs. A run that produced no measurement is left out of the calculation, so skipped and errored runs move neither number. Run History lists them all.
Why was a run skipped?
Decube skips a run when it has nothing to evaluate. There are two causes:
No data. The table held no rows in the scanned window, so a check like Null has nothing to measure. Volume monitors are the exception, because a count of zero is a result they are meant to report.
No previous data. The monitor compares against the previous period and that measurement is missing, either because this was the first run or because the earlier collection failed.
What happens to my history when I change the configuration?
It depends on the field. Schedule and detection method archive the current version and start a new one, which keeps the old readings attributable to the rules that produced them. Threshold, attributes, and data quality dimension apply in place, and the history stays continuous.
Does disabling a monitor affect its open cases?
Disabling stops the monitor from running, so it raises no new incidents. Cases that are already open stay open, and you can close them as usual.
Last updated