Notifications

The panel can warn the administrator about important things on its own: a user is approaching the traffic limit, never connected, or the subscription is about to expire. Notifications go to Telegram and to webhooks — the channels are independent and can be enabled separately.

Telegram

Telegram notifications are off by default. Enable them and set up the bot:

Variable	Default	Description
IS_TELEGRAM_NOTIFICATIONS_ENABLED	false	enables Telegram notifications
TELEGRAM_BOT_TOKEN	—	bot token, required when enabled
TELEGRAM_BOT_API_ROOT	https://api.telegram.org	Bot API address; change it for a local server
TELEGRAM_BOT_PROXY	—	proxy, for example socks5://proxy:1080

Where exactly to write is determined by separate variables:

Variable	Which events
TELEGRAM_NOTIFY_USERS	users and subscriptions
TELEGRAM_NOTIFY_NODES	node status
TELEGRAM_NOTIFY_CRM	infrastructure payments
TELEGRAM_NOTIFY_SERVICE	panel logins, API tokens, startup
TELEGRAM_NOTIFY_TBLOCKER	torrent-blocker reports

IS_TELEGRAM_NOTIFICATIONS_ENABLED=true
TELEGRAM_BOT_TOKEN=123456789:AA...change_me
TELEGRAM_NOTIFY_USERS=-1001234567890:80
TELEGRAM_NOTIFY_NODES=-1001234567890:81

chat_id:thread_id format

The value of each variable is either chat_id or chat_id:thread_id for topics in a supergroup. One chat is specified per section.

Example	Meaning
-100123	a chat or channel, no topic is used
-100123:80	chat -100123, topic (thread) 80

The chat_id of a group or channel is always negative; private chats are positive. thread_id is the number of the topic the bot should write to.

warning

Add the bot to the chat you need and grant it permission to send messages. For topics, the bot must be a member of the group and have access to topics — otherwise Telegram returns an error and the notification is lost. Check delivery right after setup.

Traffic thresholds

The event arrives when a user has used up a given share of the limit.

Variable	Default	Description
BANDWIDTH_USAGE_NOTIFICATIONS_ENABLED	false	enables threshold notifications
BANDWIDTH_USAGE_NOTIFICATIONS_THRESHOLD	[60, 80]	thresholds in percent, in ascending order

There can be no more than five thresholds, each an integer from 25 to 95. The event fires once per threshold: the panel remembers the highest threshold passed and does not repeat the notification. Only active users with a set traffic limit are counted. The check runs every 5 minutes.

If there are too many notifications, a separate errors.bandwidth_usage_threshold_reached_max_notifications event arrives — it signals that more users were processed in a single pass than allowed.

Users who never connected

Useful when access has been issued but the user has not set up a client.

Variable	Default	Description
NOT_CONNECTED_USERS_NOTIFICATIONS_ENABLED	false	enables notifications
NOT_CONNECTED_USERS_NOTIFICATIONS_AFTER_HOURS	[6, 24, 48]	hours after user creation

No more than three values, each an integer from 1 to 168, in ascending order. The countdown starts from the moment the user was created, not from when the subscription was issued. The check runs every 10 minutes. The event carries meta.notConnectedAfterHours with the actual threshold.

note

For performance reasons, the activeInternalSquads and lastConnectedNode fields in such events are empty. Do not use them when processing.

Subscription expiry

Reminders arrive before and after expireAt, depending on the sign of the value.

Variable	Default	Description
EXPIRATION_NOTIFICATIONS_ENABLED	false	enables reminders
EXPIRATION_NOTIFICATIONS	[-72, -48, -24, 24]	hours relative to expireAt

Sign	Meaning	Example
negative	the subscription expires in this many hours	-24 — one day before
positive	the subscription expired this many hours ago	24 — one day after

Zero is not allowed. Values are integers from −168 to 168, in ascending order, without duplicates; no more than five negative and five positive. The event contains meta.expiration with the same number. The check runs once a minute.

Fine-tuning the channels

Besides the general switches, there is the file /var/lib/remnawave/configs/notifications/notifications-config.yml inside the container. It states, for each event, whether to send it to Telegram and to webhooks, and you can add separate webhook addresses.

events:
  user.expired:
    telegram: true
    webhook: true
  service.login_attempt_failed:
    telegram: true
    webhook: false
    additionalWebhookUrls:
      - https://example.com/xlada/security

tip

An event that is missing from this file counts as disabled. If a notification does not arrive, first check whether the event is described in the config and whether the required channel is enabled.

Notification jobs run only when at least one channel is enabled — Telegram or webhooks. CRM infrastructure payments are checked once a day, at 17:00. Failed panel logins are recorded in service.login_attempt_failed, and the password itself is never included in the notification.

What's next

• Webhooks — events, payload signing, and retries.
• Environment Variables — the full .env breakdown.
• Device Limit (HWID) — device events.
• Common Errors — if notifications do not arrive.