# Panel notifications (iContact messages)

# Overview

Besides the event notifications that the server sends by itself, Imunify delivers generic panel notifications (also referred to as iContact messages) through the hosting panel's own notification mechanism:

• cPanel/WHM: delivered via cPanel iContact (WHM → Contact Manager)
• Plesk: delivered by the Imunify Plesk extension via Plesk Notifications (Tools & Settings → Notifications / Notification Center)

The two channels are entirely separate, and the difference matters when you are deciding where to look for a missing message:

# How they are produced and delivered

1. The agent uploads server telemetry (scan results, detected applications, configuration) to the Imunify cloud.
2. The cloud evaluates that telemetry and prepares a notification with a ready-made subject and HTML body, together with a period limit for that message type.
3. The agent asks the cloud for pending notifications no more than once every 24 hours.
4. Before delivering, the agent applies the period limit it received, so the same message type is not repeated more often than the cloud allows.
5. The message is handed to cPanel iContact or to the Plesk Notification Center, which decides the actual recipients and channels.

Two consequences follow from this design and account for most support questions:

• There is no "send me a test notification" action. The content is generated in the cloud, not on the server, so it cannot be triggered locally.
• A configuration change is not reflected immediately. It reaches the cloud with the next telemetry upload, the cloud evaluates telemetry from the last few days, and the server asks for messages once a day — so a change can take more than a day to show, in either direction.

# Message types

Seven message types have a switch of their own. Six of them are addressed to ImunifyAV and ImunifyAV+ servers and are never generated for an Imunify360 server; the only type that applies to every product is Vulnerable scanner version. Each type has its own cooldown, and all but one pair are generated independently — the two WordPress types are mutually exclusive, see below.

# Choosing which message types to receive

Go to Settings → Notifications and click Manage panel notifications in the Panel notifications row. The dialog lists only the message types your product can receive, so it looks different on the two products.

# On ImunifyAV / ImunifyAV+

• Enable panel notifications is the master switch. Turning it off stops all panel notifications at once and greys out the individual types, which keep their own values.
• Each of the seven types below has its own toggle. All of them are on by default.

# On Imunify360

On Imunify360 the dialog offers the master switch and a single type, Vulnerable scanner version. The other six messages are addressed to ImunifyAV / ImunifyAV+ servers and are never generated for Imunify360, so their switches are not shown. The master switch is still the control that matters here: it governs every message that has no switch of its own — the outdated agent version warning, PCI compliance notices, the compromised accounts report and the like. Turning it off silences all of them; turning Vulnerable scanner version off silences that one message only.

The hidden types are not dropped from the configuration: DASHBOARD.notifications keeps all seven keys on every product, and the dialog saves the six it does not show unchanged.

Click Apply to save. The dialog writes both ADMIN_CONTACTS.enable_icontact_notifications (the master switch) and DASHBOARD.notifications (the individual types) in a single configuration update.

imunify360-agent config show | grep -A8 DASHBOARD

# Configuration keys

Panel notifications are controlled by three keys in /etc/sysconfig/imunify360/imunify360.config (or a file in /etc/sysconfig/imunify360/imunify360.config.d/):

# In YAML

ADMIN_CONTACTS:
  enable_icontact_notifications: True
DASHBOARD:
  notifications:
    malware_found: True
    malware_detected: True
    malicious_redirect_detected: True
    aibolit_vulnerable: True
    insecure_wp_core: True
    outdated_wp_core: True
    scan_not_scheduled: True

# Via CLI

Turn everything off (Imunify360):

imunify360-agent config update '{"ADMIN_CONTACTS": {"enable_icontact_notifications": false}}'

Turn off the one type Imunify360 receives and keep the rest of the channel:

imunify360-agent config update '{"DASHBOARD": {"notifications": {"aibolit_vulnerable": false}}}'

The same commands on ImunifyAV/AV+ use the imunify-antivirus binary; there all seven types apply, so any of them can be switched off:

imunify-antivirus config update '{"DASHBOARD": {"notifications": {"outdated_wp_core": false, "insecure_wp_core": false}}}'

# Disabling user-targeted delivery

If these notifications should go only to the server administrator and never to end users, disable CONTROL_PANEL.generic_user_notifications.

Imunify360 (global):

imunify360-agent config update '{"CONTROL_PANEL": {"generic_user_notifications": false}}'

Imunify360 (for a specific user):

imunify360-agent config update '{"CONTROL_PANEL": {"generic_user_notifications": false}}' --user <username>

ImunifyAV/AV+:

imunify-antivirus config update '{"CONTROL_PANEL": {"generic_user_notifications": false}}'

# Who receives these messages

A notification is addressed either:

• to the server administrator (panel admin) — when no specific user is provided, or
• to a specific panel user (customer/reseller) — when a target user login is provided.

User-targeted delivery is controlled by CONTROL_PANEL.generic_user_notifications (default: True). The final recipients and channels are then decided by the panel: WHM Contact Manager on cPanel, Tools & Settings → Notifications on Plesk.

# Licensing

Panel notifications do not require an additional add-on license. They are controlled by a configuration option and are available on supported panels where the delivery channel exists (cPanel/WHM, Plesk).

# Requirements

• Imunify360 or ImunifyAV/AV+ installed and running, with an activated license (the agent needs its cloud identity to request notifications).
• For Plesk delivery: Plesk installed, and the Imunify extension installed/enabled in Plesk.
• For cPanel delivery: cPanel/WHM installed, and WHM Contact Manager configured with at least one destination.

# Plesk: managing delivery with Plesk Notifications

When Imunify runs under Plesk, it relies on the Imunify Plesk extension to dispatch these messages via Plesk notifications.

• Where you see it: in Plesk's Notification Center, and/or as emails depending on your Plesk notification settings.
• Where you configure delivery: Plesk → Tools & Settings → Notifications (choose recipients and optionally add a custom email address).

# Manual test (advanced)

On a server with the Imunify extension installed, run:

echo '{"message_type":"Generic","params":{"subject":"Test Generic","body_html":"<p>Hello from Imunify</p>"},"user":"client_login"}' | sudo /opt/imunify360/venv/share/imunify360/scripts/send-notifications

Payload fields:

• message_type: must be Generic
• params.subject: notification subject
• params.body_html: HTML body (preferred)
• params.body / params.text: plain-text fallback (optional)
• user: Plesk login to receive the message (optional). If omitted, the Admin user is used.

This verifies the Plesk delivery path only; it does not exercise the cloud side.

# Plesk CLI (optional)

Plesk email notification settings can also be managed via plesk bin notification. See: How to manage Plesk email notifications via CLI.

# cPanel/WHM: delivery via iContact

On cPanel/WHM, Imunify uses cPanel's iContact system. To manage recipients and channels, use:

• WHM → Home → Server Contacts → Contact Manager

Make sure at least one destination (email/SMS/etc.) is configured there. Imunify only controls whether these messages are generated and handed over; delivery is handled by cPanel.

# Troubleshooting

Check what is actually enabled on the server.

imunify360-agent config show | grep -A8 DASHBOARD
imunify360-agent config show | grep -A3 ADMIN_CONTACTS

See what the agent handed to the panel. Each message the agent passes to cPanel or Plesk is logged to /var/log/imunify360/console.log with its subject and body:

grep -E "cPanel.notify|Plesk.notify" /var/log/imunify360/console.log | tail

These lines are written before the panel handler runs, so they show that a message reached the server and was handed over — not that the panel delivered it. On Plesk the extension records the outcome in /usr/local/psa/var/modules/imunify360/imunify360-local.log (Notification with subject "…" was sent to …) and Plesk reports recipient problems in /var/log/plesk/panel.log; on cPanel the message is handed to iContact, which applies the Contact Manager settings.

Nothing can be triggered from the server. The messages are generated in the cloud from uploaded telemetry, on the cloud's schedule. If the condition behind a type is present and the type is on, expect the message within the next daily poll; if it does not come, the usual reasons are the type's cooldown, the product scope in the table above, or telemetry that has not been uploaded yet. A missing Outdated WordPress version message has one more possible cause: the server also qualifies for Insecure WordPress version, which suppresses it.