Setting up notifications about 1C-Bitrix parsing errors

Setting up parsing error notifications for 1С-Bitrix

The parser populates the catalog, but you learn it crashed two days later when a manager notices outdated prices. Without an alert system, any parser is a ticking time bomb. Let's set up notifications so you know about problems within minutes, not days.

Types of errors to catch

Before setting up notifications, classify errors:

• Network — connection timeout, HTTP 403/429/503, connection reset. Parsing source is unreachable or blocking requests.
• DOM parsing — source markup changed, CSS selectors or XPath expressions return nothing. Most common type.
• Data validation — price is zero, name is empty, SKU doesn't match format. Parser got data but it's garbage.
• Import to catalog — errors calling CIBlockElement::Add() or Update(), missing required info block properties, memory limit exceeded.

Each type needs different urgency level. Network error may be temporary (retry in 5 minutes), selector breakage is systemic and needs developer attention.

Notification architecture

Bitrix's standard message mechanism — mail events (module main). Create mail event type, e.g. PARSER_ERROR_NOTIFY, with template containing macros #ERROR_TYPE#, #SOURCE_URL#, #ERROR_MESSAGE#, #TIMESTAMP#. Template registers in Settings → Mail events → Event types.

Sending from parser code:

CEvent::SendImmediate('PARSER_ERROR_NOTIFY', SITE_ID, [
    'ERROR_TYPE' => 'DOM_CHANGED',
    'SOURCE_URL' => $url,
    'ERROR_MESSAGE' => 'Selector .price-block returned empty result',
    'TIMESTAMP' => date('Y-m-d H:i:s'),
]);

Method SendImmediate sends email immediately, bypassing b_event queue. For parser errors, this is the right choice — queue delay can reach several minutes.

Problem of spam: if source goes down, parser generates hundreds of identical errors. Solution — deduplication by key. Before sending, check in b_option or separate table whether notification with such ERROR_TYPE + SOURCE_URL was sent in last N minutes. Suppression interval — 30-60 minutes for network errors, no suppression for validation errors.

Channels besides email

Email is slow. For critical errors, add Telegram or Slack via Bitrix REST API or directly:

• Bitrix24 webhooks — if you have Bitrix24 portal, send message to chat via im.message.add incoming webhook. Notification arrives instantly in mobile app.
• Telegram Bot API — file_get_contents('https://api.telegram.org/bot{TOKEN}/sendMessage?chat_id={ID}&text=...'). Simplest option without dependencies.

Set urgency threshold for each channel. Routing table:

Logging as foundation of notifications

Notifications are built on top of logs, not instead. Log each error to b_event_log via CEventLog::Add() with parameters AUDIT_TYPE_ID = 'PARSER_ERROR' and MODULE_ID = 'iblock'. This gives history in standard Bitrix event journal (Settings → Tools → Event Log), filtering by types, auto-rotation.

Based on log entries, build aggregated reports — agent run hourly, counts errors and sends digest if threshold exceeded.

What to setup in one working day

1. Mail event type + template with variables.
2. Wrapper ParserNotifier::send($type, $context) with deduplication.
3. One additional channel (Telegram or Bitrix24).
4. Error logging to b_event_log for history.
5. Verification — simulate failure and confirm alert delivery.