Error notifications via email, SMS, and messengers

What this solution does

The module "Error Notifications via Email, SMS, and Messengers" integrates with the standard Bitrix exception handler and sends notifications to administrators regarding unhandled errors and critical failures. Notifications are delivered via email or SMS/messengers using already configured site email events and SMS providers.

The module does not replace the Bitrix error log but complements it by registering as an additional handler. Upon an unhandled exception, it triggers standard Bitrix events (CEvent and the messageservice module's SMS event). The module does not send emails directly; delivery depends entirely on existing site settings, including email templates, SMS gateways, and messenger integration via messageservice.

Email and SMS/messenger notifications are implemented as two independent events that can be enabled, disabled, and configured separately using standard Bitrix tools.

The module groups identical errors to prevent notification duplication. Errors matching by class, text, code, file, line, type, and source are accumulated in a queue and sent as a single notification with a repetition count. The default sending interval is one hour. Errors originating from different modules are processed separately and are not merged, even if their text is identical.

Critical errors, including fatal errors and unhandled exceptions, can be configured for immediate delivery regardless of the grouping mode. This ensures administrators are promptly notified of critical site failures. This feature is controlled by a dedicated setting and is enabled by default.

The Rover\Notifier\Notifier::report() method allows sending arbitrary messages from site code or other modules through the same infrastructure used for automatic error notifications. This is convenient for manual alerts, such as a failed order payment. Any additional fields can be attached to the message and will be available in templates as placeholders. These messages follow the module's general settings: they are not sent when interception is disabled and participate in grouping alongside caught errors.

The source of the issue is automatically indicated in the notification: the core, a specific module (by its identifier, e.g., rover.amosale), or site code. The module determines this automatically based on where the error occurred, so manual labeling is not required. The error type is displayed in a readable format (FATAL, UNCAUGHT_EXCEPTION, etc.) rather than as a service numeric code.

The grouping interval is configurable via the module's administrative panel without code modifications.

The module is ready to use immediately after installation. Upon activation, email and SMS event types are automatically created along with templates containing placeholders for error text, source, type, code, file, line, stack trace, and repeat count. Emails begin arriving as soon as the module is enabled. The SMS template is created in a disabled state; you must specify a recipient and enable it to use it. For delivery to Telegram, WhatsApp, or MAX, the standard 'Notification Service' module with a suitable sender connector must also be installed.

During uninstallation, the module safely removes itself from the exception handler configuration, deletes the agent and queue table, and optionally preserves created events and templates if the corresponding option is selected.

The module never interrupts the main exception handler. Any errors occurring within the solution itself (such as database unavailability or missing SMS template configuration) are intercepted and handled internally, ensuring the site continues to operate normally.

Protection against repeated handler invocation within a single request prevents duplicate notifications from being sent.

The error grouping queue is stored in a separate table via the Bitrix ORM. A scheduled agent processes this queue and automatically cleans it up after execution.

Additional fields passed along with the message survive the grouping queue and are correctly inserted into the summary notification template. This ensures that no placeholders remain unresolved in the final email.

If grouping is disabled, all accumulated error messages are sent to the recipient immediately.

The module does not deploy its own delivery infrastructure; instead, it utilizes the existing communication channels on the project. This prevents conflicts with current integrations and allows for easy deployment in projects of any scale.

Error prioritization relies on the standard exception handler constants of Bitrix (FATAL, UNCAUGHT_EXCEPTION). A separate priority system is unnecessary as the solution fully leverages core capabilities.

The administrative panel displays the real-time system status: the number of messages waiting in the send queue (with a direct link to the table) and the scheduled time for the next grouping agent run. This allows for process monitoring without requiring direct database access.

Who is it for

A module for developers and agencies supporting commercial projects. It ensures timely notifications about fatal errors via email, SMS, and messengers. The system prevents a 'storm' of identical messages during mass failures and operates without modifying the site's code after installation.

General iT can install and configure this module and check how it works on your website.