Monitor operations

Every monitor is listed on the all monitoring page, with its actions at the end of its row. This page describes each of them.

Where monitors live

Every monitor, whatever its type, is listed on one page: all monitoring (the list icon in the top bar, or #/all). Each row carries the monitor’s current status, type, probe, the applications it belongs to, its last response time and a trend sparkline, its schedule, tags, last check and state.

The all monitoring page: one row per monitor with status, type, probe, app, response, trend, schedule, tags, last check, state and actions

Available operations

The four most common actions sit directly in the Actions column; everything else is in the ⋮ More actions menu at the end of the row.

Inline row actions: edit, enable/disable, run, stats/report and more actions
Icon Action Go to
pencil Edit the monitor Edit monitor
toggle Disable / Enable the monitor Disable / enable
play Run test (EUM: Run (shadow mode)) Run a monitor now
pie chart Stats / report Display report
⋮ More actions see below
More actions menu of an EUM monitor

The More actions menu holds:

  • View config — read-only view of the definition. See View monitor.
  • Copy — opens the form pre-filled to create a duplicate. See Duplicate monitor.
  • Compute threshold — recompute the thresholds from history. See Compute threshold.
  • EUM monitors only: Run in browser mode, Kill execution, Live-view logfile, Download logfile, Download HAR (not for GUI-mode monitors), Download all files, Screenshot on error.
  • Admins only: Clean historical data and Delete.

SNMP and WMI rows have no Edit, Copy or Compute threshold: they are configured on their device (see SNMP & WMI evaluation). Users of the viewer group see no actions; the user group sees everything except Clean and Delete.

Every action shows a small spinner in the row while it runs, and its outcome is reported in a notification at the bottom right of the page.

Display report

Click the pie chart (Stats / report). The report opens in a side panel over the list, for the last 6 hours by default; change the range in the selector at the top right, re-run the monitor with the play button, email the report with the envelope, or switch Detailed off for a summary.

EUM monitor report side panel: transactions waterfall, status stats, timeline, performance over time and Web Vitals charts

The header repeats the monitor’s tags and thresholds. For an EUM monitor the report starts with the transaction waterfall (mean or last run, with a screenshot per step and its Web Vitals), then the status statistics, the status timeline with its min / max / mean and 24h / 7d / 4w trends, performance over time, per-transaction charts, heat maps by hour and by day, and the Web Vitals series. See Reading reports for the scheduled, emailed variant.

Live view

EUM monitors. In More actions, choose Live-view logfile. The probe’s log for this monitor streams into a window and keeps refreshing while it is open. Run test and Run in browser mode open the same window automatically, so you can follow a run as it happens.

Live view of an EUM monitor logfile

Disable and enable a monitor

Click the toggle icon. It acts immediately, without a confirmation: the row’s State switches to disabled and the icon becomes Enable. A disabled monitor keeps its history but is no longer scheduled; its row is greyed out. Click the toggle again to enable it.

Run a monitor now

Click the play icon to run the monitor once on its probe, outside its schedule.

  • For URL, API, TCP, UDP, Ping, DNS, Database and System monitors this is Run test: the result is reported in a notification.
  • For an EUM monitor this is Run (shadow mode): the scenario runs headless, in the background, and the live logfile window opens so you can watch it.
  • Run in browser mode (More actions, EUM only) runs the scenario in a visible browser on the probe host, which is useful to watch the interaction with the website.

For statuses see Monitor statuses.

Kill a running monitor

EUM monitors. In More actions, choose Kill execution. The notification tells you whether the process tree was killed or whether the monitor was not running.

Monitor statuses

The Status column, the reports and the notifications use the same colours:

Monitor status colours
  • OK (green): the run succeeded; the value is the time it took.
  • MINOR (yellow), MAJOR (orange), CRITICAL (red): the run succeeded but the corresponding threshold was crossed.
  • ERROR (dark red): the check failed — target unreachable, pattern not found, script step failed.
  • EXCEPTION: the monitor could not start.
  • CONFIG: the monitor’s configuration is missing on the probe.
  • TIMEOUT: the run exceeded the monitor’s timeout.
  • NO DATA: the monitor has not reported yet; a disabled monitor is greyed out.

Overlap is reported only by Run test: an instance of the monitor is already running. It is not recorded as a status.

Delete monitor

Admins only. In More actions, choose Delete, then confirm with OK (or Cancel).

Delete confirmation dialog

If the monitor is still referenced by a report or a downtime, the deletion is refused and the notification says so. Remove it from those reports and downtimes first.

Clean monitor

Admins only. In More actions, choose Clean historical data, then confirm. The monitor’s performance and status history is purged — this cannot be undone — and its trend sparkline empties. The definition itself is kept and the monitor keeps running.

Last logfile monitor

EUM monitors. In More actions, choose Download logfile to download the log of the last run.

Last HAR file

EUM monitors. In More actions, choose Download HAR to download the HAR of the last run. The report’s HAR viewer shows the same file inline. Not offered for GUI-mode monitors, which record no HAR.

Download run files

EUM monitors. In More actions, choose Download all files to download an archive of all the files of the last run. Screenshot on error downloads the screenshot taken when the last run failed.

View monitor

In More actions, choose View config. The monitor’s definition opens read-only, with the same tabs as the edit form. Close it with the ✕ at the top right.

Read-only view of a monitor definition

Duplicate monitor

In More actions, choose Copy. The form opens pre-filled with the monitor’s settings (and, for EUM, its script and actions). Change the name and whatever else differs, then save with the disk icon. The copy appears in the list.

Edit monitor

Click the pencil. The form opens full screen, with one tab per concern — for an EUM monitor Settings, Advanced, Script and Actions; for URL and API monitors Settings, Advanced, Actions and Prediction. The name is locked; the header shows who changed it last.

Edit form of an API monitor: definition, probes, schedule, tags, thresholds and specific settings

Change what you need and click the disk icon at the top right to save, or ✕ to close without saving.

Add a monitor

Click the + next to the search box and pick the type. The same form opens empty.

New monitor type picker

Compute Threshold monitor

In More actions, choose Compute threshold (or click compute next to Threshold in the edit form). The thresholds are recomputed from the monitor’s history, with the method and compute range set in the probe’s Auto baselining settings, and saved; the notification shows the result. The row’s thresholds, and the report header, show the new values.

Test the monitor before saving

Every monitor form except EUM and System carries a Test button next to its target field. It runs the check right now, from the probe the monitor will use, with the values currently in the form — and returns a step-by-step verdict without saving anything, writing any history, changing any status or raising any alert.

  1. Fill in the target (URL, endpoint, host:port, name to resolve, or connection + query).
  2. Make sure a probe is selected — the Add form uses the first probe of Push to Probes, the View/Details forms use the monitor’s own probe.
  3. Click Test. The result panel opens underneath with an overall banner, one row per check performed (request, response time, page size, each pattern group or column check, the aggregate result threshold) and an expandable Raw response.
  4. Adjust and test again until the verdict matches what you consider healthy, then Add / Update.
Test result panel under the API URL: overall banner, one row per check, raw response and Suggest pattern groups

Available for URL, API, Database, TCP, UDP, Ping and DNS monitors, plus per-row tests and a ⚡ Test all on SNMP and WMI devices. For EUM monitors, use run in browser mode instead.

See Testing a monitor for the full panel anatomy, the severity chips, the pattern-group suggestion flow and the database result-set preview.

Pattern groups (URL & API)

URL and API monitors can grade the response body, not just the response time. Each pattern group extracts one value with a regexp and checks it against its own Minor / Major / Critical thresholds; the monitor status is the most severe of every group and the response time.

The Pattern groups grid appears in the Specific section of a URL or API monitor form. Its first row is the primary group; use + Add pattern group for more.

  1. In the regexp (capture group) cell of the first (primary) row, enter your pattern:
    • Without a (capture group) it is a plain content match — the response body must simply contain the pattern (otherwise the monitor fails). The operator and threshold cells collapse into a “content match” note; response-time thresholds still apply.
    • With one (capture group) — e.g. "length"\s*:\s*(\d+) — the captured text becomes a value to grade, and the operator + threshold cells appear.
  2. Pick an operator: number > / < / ==, string == / != / contains / not contains, or datetime older than.
  3. Fill the minor / major / critical thresholds. Leave a tier blank to ignore it — a group can define only Critical, for example.
  4. Optionally set a match index (idx): which occurrence of the pattern to read. 1 is the first; bump it to reach element N of a repeated field or a JSON array (2 = second item).
  5. Use the checkbox at the start of each row to enable / disable a group — a disabled group is kept but not evaluated.
Let the endpoint fill it in. Click Test to call the endpoint live, then Suggest pattern groups. Mugnsoft inspects the response — JSON objects/arrays, or plain-text key: value and <tag>value</tag> — and proposes a name, regexp, match index and operator for each detected value, previewing what each one captures. Review, edit or untick rows, then Apply selected; the groups are added with blank thresholds for you to fill.

Click Add / Update to save. Removing or renaming a group also clears its old history on save. For the stored field format (patterns JSON, operators, datetimeFmt/datetimeTz) see Monitor Configuration → Pattern Groups.

Views: table, cards, compact

The three buttons next to hide OK switch the page between the table (default, sortable), standard cards and compact (densest cards). The choice is remembered in your profile display preferences.

All monitoring page in standard cards view

Filter monitors

Search box, status summary chips and column filters
  • Search box — type part of a monitor’s name, its type or a tag; the list filters as you type. Clear it with ✕.
  • Summary chips — the “N of M monitors need attention” bar counts monitors by status: problems, ok, no data, paused. Click a chip to show only those rows; click it again to clear. The problems chip opens a breakdown by status.
  • Column filters — the drop-downs under the headers (status, type, probe, app, location, schedule, tags, state) and the name filter combine with the search box.
  • hide OK — hides every row whose status is OK.
  • The page size selector and the arrows at the top paginate the list; the refresh button reloads it.

Select rows with the checkboxes to act on several monitors at once with the trash button (delete, admins only).

Mugnsoft Gitlab integration

With GitLab configured, the definition and script of a monitor can be committed to your repository and restored from it. Configure the access first: see Webserver settings → External services. GitHub, also available there, is used for repository backups (CSV snapshots).

Update to Gitlab

  1. On the all monitoring page, click the pencil of the monitor. With GitLab enabled, the edit form header carries GitLab buttons next to the disk icon: update & Push Gitlab, duplicate & Push Gitlab and get from Gitlab.
Edit form header: update and push to GitLab
  1. Make your changes and click update & Push Gitlab.
  2. Enter the commit message and click OK.
Enter the Git commit message
  1. Confirm the message. The monitor is saved on its probe, then its settings and script are committed; notifications report each step.
Confirm the Git commit message
  1. In your GitLab repository, the commit carries the message and the Mugnsoft user who made it.
Commit in the GitLab repository

Get from Gitlab

To discard local changes and restore the last committed version of a monitor:

  1. Open the monitor with the pencil and click get from Gitlab.
Edit form header: get from GitLab
  1. Confirm. The current settings and script are replaced by the last commit, and a notification reports the result.
Confirm retrieving the last GitLab commit

See also

Translations