Bitrix24 Integration Monitoring

Bitrix24 Integration Monitoring

Integrations are the most fragile part of any Bitrix24-based ecosystem. A broken REST webhook from 1C, a failed telephony connector, a dead lead import from ad platforms — the business does not notice these failures immediately. Hours or even days pass before someone stumbles on a symptom: "Where did the leads go?", "Why aren't payments showing up in CRM?".

Integration monitoring is an early warning system that reports failures before users notice them.

What to Monitor

Every integration can be broken down into three levels of checks:

Availability level: is the data channel working? (REST endpoint responds, webhook accepts requests, message queue is not overflowing)

Correctness level: is data being transferred without errors? (no failed records in logs, field values match expected types)

Freshness level: is data being transferred on time? (last synchronization was no more than X minutes ago, new record counter is increasing)

The third level is often overlooked, which is a mistake. An integration can be technically "working" while data arrives with a 6-hour delay due to a stuck cron job.

Built-in Bitrix24 Tools

Event log: Settings → Event Log — records REST API errors, webhook failures, and module issues. Not the most user-friendly interface, but informative.

Webhook queue status: on On-Premise, inspect the b_event_message_exec table — accumulation of unprocessed events indicates a problem.

REST API log: for marketplace applications, request logs are available via Applications → [application] → Logs.

External Monitoring via Ping Integrations

The most reliable monitoring approach is when the integration itself periodically "pings" the monitoring system to signal that it is alive. Using Healthchecks.io (or a similar service):

// In the integration script (e.g., lead import from ads)
function syncLeadsFromAds() {
    try {
        $leads = fetchLeadsFromFacebook();
        foreach ($leads as $lead) {
            CRest::call('crm.lead.add', $lead);
        }
        // Signal "all good" to the monitoring system
        file_get_contents('https://hc-ping.com/your-uuid');
    } catch (Exception $e) {
        // Signal failure
        file_get_contents('https://hc-ping.com/your-uuid/fail');
        logError($e->getMessage());
    }
}

Healthchecks.io sends a notification if the signal is not received within the expected time window. This catches "silent" failures — when the script simply stops running.

Bitrix24 REST API Monitoring

Bitrix24 enforces REST API rate limits: in the cloud — 2 requests/second with batch request limits. Exceeding them returns QUERY_LIMIT_EXCEEDED. Monitor this:

// Check current rate limit via REST
$response = CRest::call('app.info');
// Response contains REQUESTS_LEFT and TIME_RESET
$requestsLeft = $response['result']['REQUESTS_LEFT'];

if ($requestsLeft < 100) {
    sendAlert("Critically low REST requests remaining: $requestsLeft");
}

For On-Premise, limits are configured in /bitrix/admin/settings.php and are considerably higher, but they are still worth monitoring under heavy integration load.

Integration Status Dashboard

Create an internal dashboard page showing the status of all integrations. Minimum required fields:

Build this on top of the b_option table (which stores last-sync timestamps) or a dedicated monitoring database.

Set up alerts in a messaging app (Telegram bot, Slack) — email is rarely read promptly, whereas messenger notifications get immediate responses. For critical integrations (payments, ad leads), the target alert response SLA should be no more than 15 minutes during business hours.