Alerts into tickets and notifications

An alert on its own stays in the alert list. Alert rules decide which alerts become tickets, in which queue, at what priority and for whom, whether the ticket resolves itself when the alert clears, and who outside your team is emailed. Digests send a summary on a schedule. Your personal notification settings decide how alerts reach you.

Alert rules#

Open Settings > Alert rules (the Alerts settings link at the foot of the Alerts sidebar goes there too). The page has two tabs: Alert rules, described here, and Alert types, the same switches as Alerts > Alert types.

Rules are tried from the top, and the first enabled rule that matches an alert decides what happens to it. An alert no rule matches stays in the alert list. Each rule shows what it matches, what it does, how many alerts it has matched and when it last did.

Below the rules, Recent alerts shows what the rules, as they stand, would do with the latest alerts, and which rule would take each one. Nothing is changed; it is a safe way to check your rules.

Create a rule#

1. Click New rule and give it a Name, for example Backup failures at Acme. Leave Enabled on.
2. Under When an alert matches, pick any of:
   • Source: every source alerts come from, grouped by area (Devices and monitoring, Patching and software, Printers, Backup, Security, Infrastructure and domains, Telephony, Licences, billing and purchasing, Platform and the rest). Click an area's name to pick or clear the whole area, or a chip to pick one source. Security, for example, covers security detections, vulnerabilities and device hardening, so a rule can route or ignore Vulnerabilities, Domains, Licences or Procurement on their own. None picked means any source.
   • Severity: Critical, Warning or Info. None picked means any severity.
   • Customers: none picked means any customer.
3. Under Then, choose Open a ticket or Ignore the alert.
4. For a ticket, choose the Queue, Priority, Type (such as Incident or Alert) and Assign to (or leave it for the queue to pick up).
5. Tick Resolve the ticket when the alert clears if you want it closed automatically. It only resolves when every alert on the ticket has cleared and nobody has replied to the customer.
6. Optionally turn on Also email about these alerts (below).
7. Use Test against recent alerts to see which recent alerts the rule would catch, then click Add rule.

A rule can also be limited to chosen alert types, shown as chips you can take off in the editor; the list then says which types it covers. Rules made by the Makes tickets switch on Alert types work this way and carry a From Alert types badge. See Alert types.

If a rule picks sources and a source has been added since it was saved, the rule says so on Settings > Alert rules and in its editor ("This rule doesn't cover ...: add them?"), with Add them and Keep as it is. A rule always keeps matching exactly what it did until you choose. A source that no longer raises alerts stays on the rule as a chip under No longer raises alerts, so you can take it off.

A new install has the rule Failed vulnerability fixes become tickets first in the list. See Vulnerability management.

The same problem again (same source and the same underlying issue) is added to its open ticket instead of opening another. Alerts that are not for a customer never open tickets. A monitoring policy can also cap Open tickets per problem: when the same problem appears on more devices at one customer, they join the newest ticket with a note instead of opening more.

One cause makes one ticket. Alerts gathered under one root cause (a tenant's lost connection, one backup source, one CVE on many devices) share the parent alert's ticket, an alert opened soon after another of the same cause joins its open ticket, and a security detection that is part of an incident joins the incident's ticket. The rules judge a parent alert as its first alert, so a rule for backup alerts also makes the ticket for the backup alerts it gathers.

A re-check that finds a problem still there never opens another ticket or tells anyone again. A snoozed or held back alert is offered to the rules only when it is released. An alert whose type is turned off raises nothing, so no rule sees it. See Alert types.

Under the recent alerts, Alerts to tickets has Reopen an alert's ticket within: when an alert that resolved its ticket by clearing comes back within that many hours, the same ticket opens again instead of a new one. Set it to 0 to always open a new ticket.

Emailing customers and their own IT#

Also email about these alerts emails the alerts a rule matches, whether or not it opens a ticket. A rule set to Ignore the alert can still email, so you can email a customer's own IT without making tickets.

• Contacts: chosen contacts of the alert's customer. Contacts are only ever emailed about their own customer's alerts.
• Everyone with a contact role: for example the customer's technical contacts.
• Other addresses: their own IT, a partner or anyone else.
• Least severity: Info and worse, Warning and worse or Critical only.
• Recovery emails: email again when the alert clears.
• When: At once, Gathered hourly or Gathered daily.

Every email says what raised the alert in a Raised by line, with its key facts. Emails to addresses a rule names leave out the link to the record, because those readers are often the customer's own people and the link opens your Tenvara.

Every email has an unsubscribe link. Addresses that have unsubscribed are listed under Unsubscribed from alert emails on the Digests tab of Settings > Notifications, where you can add or take one off.

Order, switch off and edit#

• Drag a rule, or use the up and down arrows, to change the order. Put narrow rules (one customer, one source) above broad ones.
• Use the switch to disable a rule without deleting it.
• The ... menu edits or deletes a rule.

Tip: A common set-up is a first rule that ignores info alerts, then rules for the sources you care about most, then a catch-all such as Critical alerts become tickets at the bottom.

Digests#

A digest is a summary emailed on the days and at the time you choose, to staff and to any other address. Set them up on the Digests tab of Settings > Notifications.

1. Click New digest and give it a Name.
2. Under What it covers, tick Open alerts by customer, The last day of alerts, Email security and Backup.
3. Choose the Customers (none picked means every customer), the People and any Other addresses.
4. Pick the Days, the time (At) and the Time zone, and leave it On.
5. Click Add digest.

In its first email of each week, every digest also names the Noisiest five this week: the five alert types and security rules with the most noise for the digest's customers in the last 7 days, each with how many of its items were noise. See How did it end? Closing alerts and the noise figures.

Preview on a digest shows what it would say now, and you can send a test to yourself. Staff get it in their own language; other addresses get an unsubscribe link.

Once a month, in its first email of the month, every digest also asks Still off, still wanted?: the alert types that have been off for more than 90 days with no end date, with who turned each off, since when and why, and a button to Alert types.

How alerts reach you#

Each person chooses where notifications reach them on the Yours tab of Settings > Notifications. In What reaches you where, the Alerts and security group has:

• Critical alerts: a critical alert opens for a customer.
• Alerts given to you: an alert is given to you, one of yours gets worse, or a ticket is raised from it.
• Other alerts: alerts below critical that are sent to you.
• Onboarding findings: the first scan of a newly onboarded customer, tenant, domain or set of devices finished.

Tick the channels you want for each. You start with the defaults for your role, and quiet hours hold back everything but on-call pages. See Notifications.

Wherever an alert reaches you (the inbox, a desktop or push notification, a text, an email, a Teams or Slack card or an on-call page), the message leads with Raised by: the record behind the alert, its key facts and a link to it.

A security incident sends one notification, which is updated as its response clock runs, rather than a new message for each detection that joins it.

Once an alert becomes a ticket, the usual ticket notifications apply too, such as Assigned to you.

Out of hours: on-call#

Out of business hours, each queue is handled by nobody (alerts and tickets wait for the morning, with an optional page for Critical), your own on-call rota, or a third-party provider. For alerts that must reach someone at night, use the on-call rotas in Team > On-call. Critical alerts can page whoever is on call when they open, automation rules can page too, and a page escalates if nobody acknowledges and records who did. When you are on call, Settings > Notifications says so at the top, and pages reach you whatever your quiet hours. See On-call.