Alerts
Work the alert list across every source, group it, read an alert with the chart around when it fired, and take, snooze, acknowledge, resolve with how it ended or add it to a ticket.
Alerts on the rail is one list for everything that needs attention across Tenvara: monitoring, patch management, backup, Microsoft 365, security, vulnerabilities, infrastructure, domains, software, printers, documentation, licences and billing, remote access and more. Every alert says what raised it, and many offer the fix.
One alert per problem
Each problem has one alert. When a later check finds the same problem, Tenvara adds to the existing alert rather than opening another: Count goes up and Last checked moves on, but nobody is told again and the alert keeps its place in the list. When a monitoring rule gets worse (a disk going from warning to critical), the same alert changes severity and title.
An alert's age is always when the problem first opened. Lists show it in the Opened column (for example 19 hr ago), and hovering shows Open since and Last checked.
A problem that cleared by itself and comes back soon reopens its earlier alert rather than opening a new one: the count goes up and, if it keeps coming and going, the alert shows as Flapping. How soon counts is A problem that comes back within this long reopens its alert in Settings > Monitoring > Alert noise. Several alerts with one cause (one Microsoft 365 tenant, one backup source, one CVE on many devices, a device that is offline) are gathered under one alert that lists them. See How Tenvara decides what reaches someone.
Alerts move through three states:
| State | Meaning |
|---|---|
| Open | The problem is current. |
| Acknowledged | Someone has said they are on it. It stays in the open views until it is resolved. |
| Resolved | It cleared by itself (most monitoring alerts do when the problem goes away), or someone resolved it. A resolved alert can be reopened. |
Finding alerts
The sidebar has views, alert types and sources:
- Open and acknowledged (where the area opens), Mine, Nobody's, Not yet acknowledged, Open critical, Acknowledged, Snoozed, Flapping and Resolved. All alerts, which lists every alert whatever its status, is in the Views picker above the list with the rest.
- Alert types: every kind of alert, to turn on or off. The number beside it is how many types are off, and the list says so too (for example 1 alert type off beside the title). See Alert types.
- By source, with a count of what is open from each.
- Alerts settings, which opens Settings > Alert rules.
At the top of the page, the Alerts and Maintenance windows tabs switch between the list and every maintenance window. See Maintenance windows and mutes.
Group by above the list groups it by Type, Customer or Device (or None), and a saved view keeps the grouping.
In the list, filter by Severity, Status, Source, Customer, Device criticality, Owner, Held back, Acknowledged, Tags and when it opened. Search with /, sort by any column, add the Last checked column with Columns, and save your own views with Views. The list always puts open alerts first, worst severity first, then the newest problem. The Source filter offers every source alerts come from, named the way alert rules name them.
Alerts of inactive customers are left out of the list and its counts. Include inactive customers in the toolbar brings them back, and choosing the customer in the customer switcher always shows its own. When inactive customers still have open alerts, a line above the list says so, with Show the alerts.
Held back marks an alert that is open but has told nobody yet: it is waiting out a short grace period in case the problem fixes itself, snoozed, flapping, gathered under its root cause or a parent device that is down, part of an alert storm, on a device in maintenance, or about something marked as test or lab. See Alert history, dependencies and flapping and Alert storms and first-run findings.
Reading an alert
Click an alert to open it in the side panel, or use the expand button to open it full page.
The panel shows:
- the severity, status and source;
- Raised by: the exact record behind the alert as a link (the disk, check or service, the device's vulnerability, the backup, the finding, the certificate), whether it is Still true, and its key facts. The link opens that one record, or its list filtered to it with the row marked or its panel open, never a whole list;
- Can we fix it?: the fix the alert's module can run for you, with a preview first, or a line saying there is nothing to automate with a link to the runbook. See What raised an alert, and fixing it from the alert;
- for monitoring alerts, a chart of the metric or check around when it fired, with Fired marked and the thresholds drawn. For an offline alert, the chart goes back to the last data so the gap shows;
- The rule: the check or threshold behind it, in words, and the policy it comes from (click through to edit it);
- the Customer, Device, Device criticality, Owner, Ticket, how many Occurrences, Opened and Last checked;
- the alert's Activity, with notes from the team.
Acting on an alert
| Button | What it does |
|---|---|
Take it (T) |
Makes you the alert's owner. Owner gives it to someone else. |
| Snooze | Hides it until a time you choose, with a reason. |
| Acknowledge | Marks it as taken, with an optional note. If it has no owner, you become the owner. |
| Resolve | Closes it, with an optional note on what was done and a reason. |
| Raise ticket | Opens a ticket for it. The arrow beside it adds the alert to an existing ticket instead. |
| Ticket #... | Opens the ticket the alert is on. |
| Mute | Mutes this monitoring rule on this device for a while. |
| Run checks | Runs the device's checks now, to confirm a fix. |
| What's using the space | On a disk alert, shows the biggest folders and files on the volume. |
| Run script | Runs a script from the library on the alert's device. See Running and scheduling scripts. |
| Power | Restarts, locks or signs out the alert's device. |
| Remote in | Opens a remote session on the alert's device. |
Owners
An alert's owner is told (through their notification settings) when it is given to them, when it gets worse and when a ticket is raised from it. The Mine and Nobody's views and the Owner filter show who has what. Automation rules can give an alert to a person or to whoever is on call.
Snoozing
Snooze works for an alert from any source, unlike a mute.
- Click Snooze.
- Choose 1 hour, 4 hours, Tomorrow 08:00, 1 week or Until... a date and time.
- Say Why. The reason is shown on the alert while it sleeps.
- Click Snooze.
A snoozed alert stays open but leaves Open and acknowledged for Snoozed. It opens no ticket, pages nobody and starts no automation. When the time comes, if it is still open, it comes back as if newly raised. Wake now ends a snooze early.
Notes, acknowledging and resolving
Add a note in the alert's Activity (type @ to mention someone). Notes can be edited by their author for a short while, and are copied into a ticket raised from the alert later as internal notes.
Resolve asks What was done (optional, shown on the alert and copied to its ticket) and How did it end?: Actioned, False positive, Expected or harmless, Our own work or Vendor routine. The answer is required, also when you resolve several alerts at once, because it counts towards how noisy that kind of alert is. An administrator can make the note required too, with A note is required to resolve an alert under Notes on alerts in Settings > Monitoring > Alert noise.
How it ended also decides what happens if the problem comes back within 7 days: an alert closed as actioned opens again, one closed as a false positive, expected, our own work or a vendor routine stays closed and only counts the repeat. See How did it end? Closing alerts and the noise figures.
Not applicable for this device
A Firewall is off alert on a machine where the host firewall does not apply (an appliance or a hypervisor host with a firewall of its own) offers Not applicable for this device, as does the firewall check in the Protection section of the device page. Give the reason; the check is no longer expected on that device, the alert goes, and the change is in the audit log. Taking the mark back on the device page makes the check count again. Tenvara also recognises a device's role by itself where it can, so such alerts are only raised where they apply.
Alerts about something that stays true
Some alerts are about a condition that stays true until someone changes it, such as a suspicious inbox rule in a Microsoft 365 mailbox. Resolving one while the rule still exists would only see it raised again at the next sync, so Resolve asks first: "The rule still exists, so this alert will come back. Mark the rule as expected instead?"
- Mark as expected resolves the alert as expected and marks the rule as wanted, so it alerts again only if the rule changes. The alert also offers this straight away as This rule is fine (mark as expected).
- Resolve anyway resolves it and keeps it quiet until the rule changes or for 30 days, whichever comes first (set under Mailboxes and mail on the Timings tab of Settings > Microsoft 365).
- Cancel leaves it open.
The note you write is kept with the alert whichever you choose. Ticking several such alerts and using the bar works the same way. See Users, groups and mailboxes.
Adding alerts to a ticket
Use the arrow beside Raise ticket to pick an open ticket (the device's and customer's tickets come first). The alert is linked to the ticket, an internal note with its details is added, and its device is linked to the ticket. To put several alerts on one ticket, for example twelve offline alerts at one site, tick them in the list and use Add to ticket in the bar that appears.
Working several alerts at once
Tick alerts in the list and use the bar that appears: Acknowledge, Resolve, Snooze, Give to, Take them and Add to ticket.
Alerts that clear themselves
Alerts resolve on their own when their source shows the problem has gone: a metric back past its clearing point for long enough, a check passing again, an offline device heard from again, a backup that runs, a tenant that connects. If a ticket was opened for the alert, the alert rule can resolve the ticket too. An open alert that nothing has raised again for a while is also checked against what raised it, and closed with a note when that says the problem is gone (Close an alert whose source says it is no longer true after, in Alert noise).
Some alerts are about something that happened once rather than a condition that is still true: the agent being stopped or tampered with, an alert raised by an automation rule, an SNMP trap with no clearing trap, or a day's Active Directory changes. These one-off alerts resolve by themselves once nothing has happened for a while, with a note saying why. If the same thing happens again within a day, the alert opens again, counts it and, with A one-off that happens again within a day goes up in severity on, goes up one severity. Set how long they wait under One-off alerts in Settings > Monitoring > Alert noise, or per policy.
Deleting or switching off the check or threshold behind an alert also resolves it, as does switching the Monitoring module off.
Turning a kind of alert off
If a whole kind of alert is not useful to you, or not for one customer, turn it off rather than resolving it every time. Alerts > Alert types lists every type by area, each with a switch, overall or per customer, and an optional end date. Off means no alert, notification or ticket; the module still records what it finds. See Alert types.
Related
Was this page helpful?
Thanks for the feedback.