Alert Configuration

Overview: Phase 6 requires at least one push alert channel to be configured before Secure Mode can be activated. Alerts notify you of security-relevant events when no one is connected to the Dashboard. On a stable system in Secure Mode, expect roughly 1–5 email alerts per week — alert volume is intentionally low.

How Alerts Work

Alerts are a push channel for events that warrant immediate attention. They are not a secondary log stream and not a replacement for the Dashboard.

Alerts are suppressed entirely in Setup Mode. Setup Mode is a high-volume observation phase — logging everything without blocking. Alerting during this phase would produce constant noise before the allowlist is complete. Alerts become active only when Secure Mode is enabled.

Configuring Alerts

From the Dashboard, select the Alert Settings screen ([e]). The screen has two tabs: Email and Fleet.

Email Tab

Configure SMTP credentials to receive email alerts directly. Required fields:

• Node ID — defaults to the system hostname; set a recognisable identifier (e.g., prod-web-03) so email subjects immediately identify the source machine when managing multiple servers
• SMTP server and Port (default 587)
• Sender and Recipient addresses
• Password (masked on entry; never displayed after saving)

Select Save to store the configuration. HeartSuite Core Secure validates all fields but does not attempt a live connection at save time. Select Test to send a test email — this is the only moment where SMTP connectivity is verified. If the test fails, the exact SMTP error code is shown:

Test email failed: [535 Authentication credentials invalid]

Check your credentials and try again. No alerts have been sent.

Once configured, the tab shows current settings with the password displayed as (set). Select Edit to modify — the password field is always blank when editing. You must re-enter the password to prevent credentials from appearing in the terminal scroll buffer.

Fleet Tab

Configure syslog and webhook delivery for fleet and SIEM integrations. All channels are independent — enable any combination.

Syslog — A toggle (Enabled/Disabled). When enabled, HeartSuite Core Secure writes all alert events to the system log via /dev/log, using the heartsuite-alert ident, LOG_AUTH facility, and LOG_WARNING severity. No additional configuration is needed on the HeartSuite Core Secure node. After enabling, the Alert Settings screen provides an rsyslog forwarding rule example for your SIEM.

Verify syslog delivery with:

journalctl -t heartsuite-alert --since "1 minute ago"

To forward to a SIEM, configure an rsyslog output rule in /etc/rsyslog.d/heartsuite.conf. See the rsyslog omfwd forwarding module documentation for forwarding syntax, and your SIEM’s own documentation for the receiving end:

• Splunk — Get data from TCP and UDP ports
• Elastic — Filebeat syslog input

Webhook — Enter an HTTPS URL. HeartSuite Core Secure POSTs a JSON payload to this URL on every alert event. HTTP (non-TLS) URLs are rejected. Example payload:

{
  "node_id":    "prod-web-03",
  "event_type": "new_program_blocked",
  "timestamp":  "2026-03-31T14:22:00Z",
  "mode":       "Secure Mode",
  "lockdown":   false,
  "paths":      ["/tmp/dropper", "/tmp/payload"],
  "count":      2
}

To receive this payload, create an integration in your incident management tool and paste the endpoint URL into the Webhook field:

• PagerDuty — Events API v2
• OpsGenie — Incoming webhook integration
• Slack — Incoming webhooks

Status JSON — A passive monitoring surface at /.hs/sys/hs-status.json, updated every 60 seconds. Ansible, Nagios, and Zabbix can read this file via SSH pull. No configuration required — always active when the alert daemon is running. This is read-only; it does not push notifications.

When Phase 6 is complete — at least one push channel configured — the Dashboard marks Phase 6 as complete and unlocks Phase 7 (Secure Mode).

What Triggers an Alert

Tier 1 — Administrative State Changes

These events fire immediately on every configured channel, regardless of accumulation windows or digest mode:

Tier 2 — Anomalous Activity in Secure Mode

These events apply a threshold filter and are active in Secure Mode only:

Never alerted under any circumstances:

• Any event in Setup Mode
• Repeated blocks of the same program–destination pair already seen in the current session
• File version activity under /tmp/, /var/tmp/, or /dev/shm/
• Dashboard sessions opened or closed
• Successful allowlist approvals

How Alerts Are Delivered

Email — 5-Minute Accumulation Window

Tier 2 events are grouped before delivery. A dropper that installs 40 payloads in 90 seconds produces one email — “40 previously unseen programs blocked in 90 seconds” — not 40 individual messages. Volume and velocity are the attack signal; 40 separate emails fragment that signal into noise.

• The 5-minute window starts on the first Tier 2 event of a given type
• Additional events of the same type within that window are added to the pending bundle
• At window close, one email is dispatched covering all accumulated events
• Events of different types accumulate independently — a network burst does not delay a file modification alert

Digest mode: If more than 3 Tier 2 emails are dispatched within a single hour, HeartSuite Core Secure switches to digest mode for the remainder of that hour. All further Tier 2 events are queued and delivered as one digest email at the hour’s end. Tier 1 events are never held — mode switches and lockdown changes are always delivered immediately.

The 5-minute window and hourly cap are fixed, not user-configurable.

Syslog and Webhook — Immediate

Syslog and webhook emit every event immediately, without grouping or windowing. SIEM platforms (Splunk, Elastic) and incident management tools (PagerDuty, OpsGenie) apply their own correlation and deduplication — grouping events before they reach these systems removes information they need.