Alerts

Alerts watch your fleet and notify you through your own channels when something needs attention. Open Alerts in the sidebar — the page has four tabs, in this order: Rules, Channels, Conditions, and Incidents. The pieces fit together like this:

• Rules — a condition + a target + a threshold + a channel. A rule is what actually fires.
• Channels — where a notification is delivered (Slack, Telegram, Microsoft Teams, or a webhook).
• Conditions — what a rule watches for: the built-in conditions Novacula maintains, plus any you author yourself.
• Incidents — the feed of firing and resolved occurrences.

Set them up in the reverse of that order: add a channel first, then author a rule against a condition.

​

Delivery channels

On the Channels tab, select New channel. Give the channel a name (it’s what rules refer to — for example Production operations), pick a type, and fill in what that type needs: Credentials are encrypted at rest and never returned to the browser — they’re write-only. To rotate one, enter a new value; leave it blank to keep the stored credential. The channel type can’t be changed after creation, and a channel that rules still use can’t be deleted until you move or delete those rules — the delete dialog tells you so and the channel’s detail view lists the rules holding it.

​

Conditions

The Conditions tab lists everything a rule can watch for, in one searchable list with two groups: Built-in — maintained by Novacula, available to every organization, and read-only — and Your conditions, which you author yourself. Each row shows the condition, when it alerts, its severity, and how many rules currently use it. Open a row for the rest: its threshold range, and the target scopes it’s available for.

​

Built-in conditions

The catalogue Novacula maintains, with the detail each row discloses: A few things to note when planning coverage:

• Block height stalled, Node offline, Node advertised address unreachable, and the three pool conditions are fixed conditions — there’s no threshold to tune, only which target they watch.
• Node advertised address unreachable watches the node’s verified public IPv4 address — the one the Hub dials to confirm reachability (see Public IP verification). It fires when that check fails three times running, which points at DNS, a firewall, or the host being down rather than at the node process itself. A delivered notification titles it Node advertised address is unavailable.
• The pool conditions give you failover visibility: they watch the members an executor serves, so target them at an Executor (or the Organization to cover them all). A delivered notification identifies the pool by its ID. Pool frontier stalled uses a fixed 15-minute window, so on a slow chain like Bitcoin it can fire during normal operation — scope it accordingly.
• Node offline is the one built-in condition with no organization scope: you author it per node, so a new node isn’t covered until you add a rule for it.
• High log error rate watches log lines by scope: at Executor scope, the executor’s own logs only; at Node scope, that node’s logs; at Organization scope, both across everything in the organization.

Every built-in condition is Warning or Critical; the Info severity exists but no built-in condition uses it. No built-in condition offers the Chain target scope — that one comes from your own metric conditions (below).

​

Your conditions

Alongside the built-ins you can author your own reusable conditions, with New condition. A condition watches one of two signals:

• Metric — pick a metric from the list Novacula publishes for your organization (a search box, not free-form PromQL), then how to read it — its current value or its change per second — over a window you choose, and whether it alerts when that value is above, at least, below, or at most your threshold. Thresholds are finite and non-negative; zero is a valid one.
• Log message — the exact text to find in log lines, and how many matches in a five-minute window should alert. Matching is case-sensitive and literal, not a pattern.

You also give the condition a name, an optional description, a severity, and how long it must continue before it fires. The dialog previews whether the condition matches current data, so you can tell a mistyped metric or log string from a quiet one before you save it. A metric condition can be targeted at a Chain — every node of that chain in your organization — provided the metric carries a chain label. A log condition can’t: its scopes are Organization, Node, and Executor. Your conditions are editable and deletable, with two guards: an edit that changes what connected rules evaluate asks you to confirm, and a condition can’t be deleted while any rule still uses it — move or delete those rules first. If your conditions can’t be loaded, the tab says so and offers a retry; the built-ins and your existing rules keep working meanwhile.

​

Rules

On the Rules tab, select New rule (or Create rule from a condition row, which pre-selects it):

• What should trigger this alert? — pick a condition. Its severity comes from the condition and isn’t editable.
• Target scope — Organization, Chain, Node, or Executor, then the specific target. Only the scopes the chosen condition allows are offered, so picking Node offline leaves Node as the only choice, and Chain appears only for one of your own metric conditions.
• Threshold — keep the condition’s default or switch on Custom threshold and set a value within its range. A fixed condition has no threshold field.
• Delivery channel — choose a configured channel. You need at least one: without a channel the form tells you “A delivery channel is required” and offers to create one first.
• Rule enabled — a disabled rule stays configured but isn’t applied. You can also flip this from the row’s Enable rule / Disable rule action later.

A live Rule preview shows the effective condition before you save; it tells you what’s still missing (a target, a channel, a valid threshold) instead of previewing a half-filled rule. Each tab has its own search box: Rules also filters by status, condition, severity, scope, target, and channel, and Channels by type, destination, and whether anything uses them. Conditions is search only.

​

What a notification looks like

Slack, Telegram, and Microsoft Teams messages are written to be read by a person, not to reproduce the underlying monitoring payload. Each message covers one rule and one affected target, and carries:

• A title with a status marker and the condition’s plain-language summary — 🔴 Critical, 🟠 Warning, 🔵 Info while firing, ✅ Resolved once it clears. On Slack the message colour matches the severity.
• Links back into the UI — to the rule that fired, to the executor, and to the affected node.
• The observed value, formatted to suit the condition: a percentage, a plain number, a duration, or errors/s. A condition that fires on missing telemetry reads No telemetry instead of a number.
• The threshold it crossed, in the same units, including the window and the “for” duration where the condition has one (for example > 85% for 5 min). Absence conditions have no threshold and omit the line.
• Duration — the UTC time it started while firing; once resolved, how long it lasted plus the start → end window.

A resolved notification keeps the value from the last firing evaluation and marks it (at trigger), so you can tell a historical reading from a current one. Webhook channels are the exception: they receive the full payload, including raw labels and the generator URL, so you can route and process it yourself. Incidents in the UI keep that raw context too — open an incident for its labels and annotations.

​

Incidents

The Incidents tab is the feed of alert occurrences:

• Each incident is Firing or Resolved — filter to All incidents, Firing, or Resolved — with started, last seen, and, once resolved, ended times.
• Acknowledge a firing incident to signal someone’s on it; the row then shows Acknowledged by and when.
• Open an incident for its full detail: Lifecycle, Alert context (severity, status, target, rule, channel), Technical identity (incident ID, fingerprint, alert name, created), and the raw Labels and Annotations. Open rule jumps to the rule that produced it.
• The target is resolved from the linked rule where possible; an incident whose target no longer exists reads Target unavailable.
• The feed updates by polling, and Load more pages through history.

An older Hub may not expose the incident feed at all — the tab then says so, and rules and channels keep working.

​

Permissions

• View alerts, channels, and incidents — any organization member.
• Create, edit, delete rules and channels, and acknowledge incidents — Owners and Admins.

Changes to rules and channels, and incident acknowledgements, are recorded in the Audit log.

​

Related

• Node monitoring — the metrics these conditions watch.
• Audit log — who changed alert configuration, and when.