Notifications

Selvara tells you about an alert or an event by email. The server it sends through is configured once for the whole instance, in Settings → Notifications; whether a given person is mailed is theirs to decide, in Profile → Notifications.

The desktop app is the other way to be told. It watches an instance over the live socket and raises a notification of its own, without the dashboard sending anything, and clicking it opens that alert. It also watches several instances at once, which mail cannot do.

Who gets notified

There is no routing table and no on-call rotation. Two things decide it — the role, and which customers the account has been granted:

An administrator is a recipient of every alert and every notifying event. A manager or an operator is a recipient when the account is granted one of the customers the alert or the event touches. A viewer is never a recipient.

An alert touches the single customer its system belongs to. An event usually does too, but a cluster event touches every customer its members belong to, so a failover in a cluster spanning two customers reaches the managers and operators of both — and somebody granted both of them is still mailed once. An event with neither a system nor a cluster belongs to no customer and reaches administrators only.

A manager or operator who has been granted nothing is therefore told about nothing, whatever their preferences say. See Users and Permissions.

Nobody is notified by virtue of being named on a customer: the contact name and email stored there are reference data for you, not an address Selvara sends to.

A recipient is mailed when the instance's SMTP is enabled, the account has an email address, and the user's email preference is on — and a user who has never saved notification preferences counts as on. So the default for a fresh account is mail, as soon as SMTP is configured.

Which means the box on the profile page is the switch that stops it. Untick it, save, and that account is no longer mailed, whatever its role.

Email

Setting up SMTP

Settings → Notifications is administrator-only and holds one form:

Field	Notes
Enable email notifications	The master switch. With it off, nothing is mailed at all.
SMTP host	e.g. smtp.example.com
Port	587 by default
Encryption	SSL/TLS, STARTTLS or None — see below
Username / Password	Credentials for the server; the password is stored encrypted
From address	The envelope sender, e.g. alerts@example.com
From name	The display name recipients see

Leading and trailing spaces and line breaks are stripped from every field when you save, so a value pasted along with a stray newline no longer fails the login.

Encryption decides how the connection is secured:

Mode	Usual port	Behaviour
SSL/TLS	465	TLS from the first byte
STARTTLS	587	Starts in plain text and must upgrade; if the server does not offer STARTTLS, the connection is refused rather than sent unencrypted
None	25	Never encrypts, even when the server offers it. Only for a relay on a trusted network

Typing 465 or 587 into the port picks the matching mode; you can still change it afterwards. A mode that does not match the port typically shows up as a timeout in the connection test.

The password is never sent back to the browser. The field stays empty when the page loads, with a note underneath when a password is stored. Leave it empty to keep the stored one; type a new one to replace it. To stop authenticating altogether, clear the username — without one, no login is attempted.

A warning appears when the from address and the username are on different domains, e.g. alerts@example.de sent through user@example.net. Receiving servers check SPF, DKIM and DMARC against the sender's domain, so such mail is often filed as spam or refused. Use a from address on the mailbox's own domain, or authorise the mail server to send for the other one. Usernames that are not addresses are not compared.

While email is disabled the page warns about a second consequence: the emailed second factor and the password reset both travel by mail, so without a working SMTP server neither is available to any account. Accounts using an authenticator app are unaffected. Plan for that before you switch it off.

The test buttons

• Test connection only opens a connection and authenticates. It proves the host, port, encryption and credentials, and sends nothing. It uses the saved settings, so save first.
• Send test email does the connection test first and then sends a short test message to the address of the administrator who pressed the button, worded in that person's own language — so the test also shows how their real notifications will read.

If the connection test fails, no mail is attempted and the page shows the server's own answer below the buttons: the error code (EAUTH, ESOCKET, …), the SMTP reply code and the full reply text, e.g. 535 5.7.8 Error: authentication failed — not just "Invalid login". A server that does not answer within 10 seconds is reported as Server not responding – check port and encryption: almost always the wrong port, or SSL/TLS against a STARTTLS port or the other way round.

What a mail contains

Both kinds carry a link back into this dashboard. The link is built from the instance's configured base URL — if that is not set, the mail still arrives but without a working link.

An alert

• Subject: the system and the series, e.g. [Alert] db1: disk:/.
• Body: the alert message, which is the rule's own name followed by the series, the condition, the threshold and the current value.
• Facts: system, customer code, metric, threshold (condition and number) and the current value, plus the time it was triggered.
• Link: the button opens the alerts page on this alert — the right tab, the card outlined and scrolled to.

The customer code is the identifier in the Customer line — the reason to keep it short and recognisable (see Customers and Systems).

An alert that escalates — crosses a stricter rule on the same metric, Disk above 95% after Disk above 85% — is mailed again the same way, with the stricter rule's name in the message. Stepping back down mails nothing.

A resolved alert

When the value comes back inside the threshold for a whole rule window and the alert then stays resolved for 30 minutes, the same recipients get a second mail: [Resolved] db1: disk:/, the same facts with the value that ended it, and when the alert was triggered and resolved. A host that stops reporting is therefore mailed twice: once when the System offline alert opens and once, half an hour later, that it is back.

The wait is what makes the mail trustworthy. A value that goes back over the threshold within those 30 minutes reopens the alert it had, without any mail at all — see Alert Rules.

No such mail goes out when somebody resolves an alert by hand, or when an alert is closed because nothing judges it any more — its rule was deleted, disabled or narrowed past the system, or the series stopped being reported.

An event

• Subject: severity, the system (or the cluster, or no system), the kind of event, and the message if there is one.
• Facts: system, customer code, cluster, severity and the time.
• Details: whatever structured data the reporter attached — the old and new agent version, the boot time, the unit name — listed as label and value.
• Link: the timeline, already filtered to that system or cluster.

Language

Every mail is worded in the recipient's own language, which is why a single alert on a mixed team produces one German mail and one English one. The text is built per recipient from their stored language preference, falling back to the instance default when they have not chosen one. Timestamps are formatted for that language too.

One exception to keep in mind: an alert's message text is assembled from the rule name you typed, so it reads in whichever language the rule was named. Everything around it — labels, severities, event kinds, buttons — is translated.

When nothing is sent

Notifications are suppressed, deliberately, in these cases:

• The system is covered by an open maintenance window. The alert is not raised at all and matching events do not notify. See Maintenance Windows.
• The system belongs to an inactive customer — the same silence, without an end time. See Customers and Systems.
• No event rule matches the event. With no event rules at all, no event ever notifies; a fresh instance ships two, one for critical events and one for the warnings worth looking at. See Event Rules.
• The event is host.group_member_added for a group that grants no admin rights. Only joining sudo, Administrators and their kind is mailed; see Event Rules.
• The event is host.rebooted or host.unexpected_shutdown on a host whose offline alerts are off, a Windows desktop by default.
• The event is system.offline or raid.degraded and the matching alert rule (heartbeat or raid_healthy, below 1) watches the system. The alert already mails when it opens and when it resolves, so the event stays on the timeline without a mail of its own. See Event Rules.
• The would-be recipient is a viewer, or a manager or operator without a grant on any customer the alert or the event touches. See Users and Permissions.
• SMTP is disabled, or the account has no email address.
• The alert's value merely changed while it stayed active. You are told when an incident starts and when it ends, not once per minute in between.

If you expect a message and none arrives, walk that list from the top, then check that the evaluation endpoint is actually being called — nothing is raised at all if it is not (see Alert Rules) — and finally Troubleshooting.