Error notifications via email, SMS, and messengers

What this solution does

The Rover Notifier module integrates with the standard Bitrix exception handler to send notifications to administrators regarding unhandled errors and fatal errors. Notifications are delivered via email, SMS, or messengers using the site's already configured email events and SMS provider. The same mechanism is available for use in custom code: custom alerts can be sent from the module or scripts to a selected communication channel.

The module does not replace the Bitrix error system log but extends it by registering as an additional handler in the exception_handling.value.log parameter. When an unhandled exception or critical error occurs, a notification is generated and sent via standard Bitrix events, including CEvent and the SMS event of the messageservice module. The module itself does not send emails directly; it only triggers a standard event, so the delivery channel depends entirely on the existing site configuration, such as the email template, SMS gateway, or messenger integration via the messageservice module.

The Rover Notifier module provides error notifications via email, SMS, and messengers. Email and SMS/messenger notifications are implemented as two independent events that can be enabled, disabled, and configured separately using standard Bitrix tools. Delivery to Telegram, WhatsApp, and MAX via the SMS event is configured depending on the connectors installed in the Notification Service module.

The system groups duplicate errors to prevent email inboxes from being flooded with duplicates. Errors accumulate in a queue and are sent as a single message with a repetition count at a specified interval (default: once per hour). Errors are considered identical if they match in class, text, code, file name, line number, type, source, and set of additional fields. An error from one module is not merged with an error from another, even if they are identical.

Critical errors, such as Fatal error and unhandled exceptions, are sent immediately without delay and without grouping, even if grouping is enabled for other errors. These messages bypass the email queue, ensuring delivery even if the cron job processing the queue is stopped, which is common during failures.

The error grouping interval is configurable in the module's administrative panel without code modification.

Notifications clearly indicate the error source: the core, a specific module (by its identifier), or site code. The module automatically determines the location of the failure.

A readable error type is displayed (FATAL, UNCAUGHT_EXCEPTION, etc.) instead of a service numeric code.

The module is ready to work immediately after installation. During installation, email and SMS event types are automatically created, along with templates containing a set of placeholders: error text, source, type, file name, line number, stack trace, and repeat counter. The user only needs to configure the SMS recipient.

A public API is provided for developers: the Rover\Notifier\Notifier::report() method allows sending arbitrary messages or exceptions from site code and other modules through the same channels. Any additional fields can be added to the template. These messages follow the module's general settings and participate in grouping alongside caught errors.

A separate setting allows using the module as a transport for its own notifications even when site error interception is disabled. This is useful if only a dedicated notification channel is needed, and fatal errors from external code are not required.

The Rover Notifier module sends error notifications via email, SMS, and messengers. In the call context, you can specify a custom email event, an SMS event, and a site identifier (EVENT_NAME, SMS_EVENT_NAME, SITE_ID). Notifications from the module use their own template and recipients, remaining separate from site-wide errors. The IMMEDIATE key sends a message immediately; it is required for code that has already grouped data and generated a complete summary.

During uninstallation, the module correctly removes itself from the exception handler configuration, deletes the agent, the queue table, and, at the administrator's option, the created events and templates. If the corresponding option is not selected, these elements are retained.

A key engineering feature: the module never interrupts the main exception handler. Any error on the Rover Notifier side itself (such as database unavailability or missing SMS template settings) is caught and suppressed within the module. The site continues to operate normally as if the notifier were not installed.

The error handler is protected against re-entry. Upon module connection, the handler accesses the database and managed cache; if these are unavailable, it may generate a new error and trigger a recursive call to itself. Re-entry is blocked by a flag, while file log writing always occurs since it requires neither the database nor the cache.

The grouping queue is stored in a separate table via the Bitrix ORM. An agent processes the queue on a schedule and cleans it up afterward. Additional fields passed from the code along with the message survive the queue and reach the template in the summary notification.

The error type is taken from the standard exception handler classification of Bitrix, not from a custom priority system. Therefore, "criticality" means exactly the same as it does for the platform itself.

The module does not create its own message delivery infrastructure; it uses the infrastructure already present on the project. This avoids conflicts with existing integrations and allows easy embedding into projects of any scale.

The Rover Notifier module is designed for developers and agencies supporting commercial projects where it is critical to receive notifications about fatal errors before the client reports them. The solution eliminates the risk of mass duplicate emails during failures and requires no changes to the site source code after installation.

For authors of custom modules and integrations, the tool serves as a ready-made notification transport channel: there is no need to create custom events, queues, or grouping mechanisms; a single code call is sufficient.

Environment requirements:

1C-Bitrix: Site Management with the main module active. Additional licenses for other core modules are not required.

PHP version 8.2 or higher.

Delivery channel configuration:

For email notifications, no additional components are needed; the system uses the standard CEvent mechanism and the site's already configured mail transport.

For SMS or messenger delivery (Telegram, WhatsApp, MAX, and others), the Messageservice module with a connected provider is required. If this module is absent, the system operates correctly in email-only mode without errors.

Grouping mechanism:

Notification grouping is handled via the standard agent mechanism of the Bitrix platform. No separate cron job configuration is required.

If “Error notifications via email, SMS, and messengers” fits the task, General iT can install the module, configure it and verify the result in the project.