Configuring the 1C-Bitrix event log: custom types and rotation

Configuring the 1C-Bitrix event log: where incidents get lost

The standard Bitrix event log writes everything into a single table with a fixed set of types: element added, authorization, error.

For incident investigation this is not enough — from a record like "element changed" it is impossible to understand who exactly edited the price, from which admin section, and what was in the field before the edit.

As a result, an engineer spends hours cross-referencing the log with web server logs and the database, and some questions remain unanswered altogether.

The second problem is the lack of rotation. The event table grows monotonically: routine operations such as bulk import or a search engine robot crawling the catalog flood it with tens of thousands of rows per day.

A useful incident record drowns in this noise, date-based queries start hitting full table scans, and cleanup is done manually and is usually forgotten until the database has already bloated.

The third is blurred types. The standard classification does not distinguish between a change made via the API, via the administrative panel, and via a scheduled agent, although for investigation these are fundamentally different scenarios with different culprits.

Custom event types close this gap: each significant action gets its own type with a clear set of fields, while routine operations are either downgraded in importance level or not logged at all.

Configuring the 1C-Bitrix event log in this form is not a matter of ticking a checkbox but of designing a schema: which actions we record, which fields we store, how long we keep them, and what we purge automatically. Let's break down how this is structured and what it delivers in practice.

What a managed log delivers: the effect in numbers

A managed log changes not the "beauty of the logs" but three measurable values: the time to the root cause of a failure, the share of recovered user actions, and the volume of noise in the sample.

With an unconfigured log, an engineer spends hours localizing an incident: the needed entry drowns among service messages, and some events are not written at all.

After configuring the 1C-Bitrix event log, a typical investigation shrinks to minutes — by a specific user, action, and time, the chain is immediately visible.

Diagnostic speed grows because events are broken down by custom types: authentication separately, order changes separately, errors in exchange with external systems separately.

Selecting by the needed type instead of reading the file end to end makes a difference of multiples, not percentages.

The share of noise in the logs drops predictably: low-value service entries go to a separate level and into rotation earlier than the rest, so only significant events remain in the working window.

Action recovery is the second half of the effect. When the log contains the author, the object, and the result of an operation, you can restore a deleted record, roll back a mass change, or prove that data was not lost.

This shifts the investigation from the "let's reproduce it again" mode to the "let's see what happened" mode.

Based on our experience, the share of actions that can be recovered from the log rather than from a backup grows from isolated cases to the majority of data incidents.

Rotation closes the third risk — unbounded growth. A retention policy by event type and archive depth keeps the volume under control: hot records are available for fast search, while old ones go to the archive or are deleted by rule.

The log stops being a dumping ground and becomes a tool you can rely on when investigating an incident.

Logging formats: built-in, extended, external

The standard log writes events to the database and displays them through the administrative section. This is enough while there are only two tasks: to see who deleted an item and to find an error after an update.

As soon as there are many events, the built-in log hits its limits: the table grows along with traffic, date-based queries slow down, and some modules write data to their own tables, so a complete picture never emerges.

Built-in log

Works out of the box and requires no separate infrastructure — that is why almost everyone starts with it. The problem shows up later: records accumulate in the same database as the working data, and they have to be cleaned up manually or by a scheduled routine.

If no retention period is set, the table outgrows reasonable volumes and starts to affect the speed of the admin panel.

Extended event types

The standard set does not cover everything: user logins, permission changes, and exchange operations with 1C often remain out of sight. An extended set of types covers these areas, but it requires discipline — enable only what is needed.

Otherwise the log turns into a stream where the needed record cannot be found, and storage grows faster than the task requires.

External storage

When there are several sites or the load is high, events are moved to external storage: the database stays light, and investigation is done through a separate environment with its own retention periods.

The price of the solution is separate export configuration, access control and format synchronization. The choice between the three options is determined not by the size of the site, but by which questions the log needs to answer.

Setup stages: from audit to handover of the regulation

Setting up an event log is not "enabling logging" but a managed process: first understand what is being written and why, then design the structure, and only then enable recording in the production environment.

Below is the sequence we follow so that the log is useful during incident investigation rather than growing into an unmanageable array.

1. Event audit. We inventory what is already being written: which handlers and modules trigger recording, which event types are actually used during incident investigation, and which duplicate each other. We record the volume of accumulated entries and the growth rate — this is the basis for design.
2. Type design. We define custom event types for specific scenarios: authorization and permission changes, order and price changes, integration operations, administrative actions. For each type we set mandatory fields — who, what, when, from which context — so that the entry can be read without guesswork.
3. Rotation setup. We set retention rules by type: critical events are kept longer, routine ones shorter. We configure automatic cleanup and archiving so that the log table does not grow indefinitely and does not slow down queries.
4. Testing on the staging environment. We run scenarios on a copy of the production environment: we generate events, verify that all are written with the required fields, that rotation triggers on schedule, and that old entries go to the archive without loss.
5. Review and fine-tuning. We look at which events turned out to be noisy and which are missing during typical incidents. We adjust the list of types and retention depth before going live.
6. Handover of the regulation. We deliver the document: which event types exist, what each one records, how long it is stored, how to read the log during investigation, and how to add a new type without modifying the core.

This sequence produces a predictable log: the right events are in place, the volume is under control, and incident investigation takes minutes instead of hours of searching through scattered entries.

What the customer retains: configurations, schemas, regulations

Setting up an event log ends not with working code, but with a set of artifacts that any engineer can use to maintain the system — not just the one who built it. Below is exactly what we hand over and why each element is needed in operation.

• Configuration files — logging rules and rotation parameters in the repository, with a change history. Any edit goes through review rather than being made by hand in production.
• Event type map — a table of "type / source / level / where it is written / retention period". From it, the on-call engineer understands in a minute where to look for the cause of a failure, and a new developer — where to add their own type.
• Retention and rotation policies — how long each type is stored, what is archived, what is deleted, how cleanup by volume and by age is configured. The log stops growing uncontrollably.
• Routing schema — how events reach storage: buffering, resending when the receiver is unavailable, separating streams by criticality.
• Instructions for the on-call shift — typical scenarios: how to check that logging is alive, how to find an event by identifier, what to do when the disk is full.
• Response regulations — which event types require immediate intervention, which are handled on a planned basis, who receives the notification.
• Acceptance checklist — a set of checks confirming that custom types are being written, rotation triggers, and old records are not lost during a rollback.

Each artifact is versioned together with the code: on the next change to the log, it is clear what changed and why. This removes dependence on a single person and makes support predictable.

Case study: how we reduced the time to find the cause of a failure

A project on 1C-Bitrix — an online store with a personal account and order exchange with an accounting system. The complaints were vague: "sometimes an order isn't created", "some customers don't receive the email".

There were entries in the standard event log, but without context — they couldn't be used to understand which specific call failed and with what data.

What it was like before setup

The engineer would open the log, see a general error, and then proceed by trial and error: reproduce the scenario manually, check the web server logs, verify the exchange with the accounting system.

A single incident took from two to four hours, and some failures weren't found at all — they occurred once every few days and left no traces.

What was changed

• Custom event types were created for key points: order creation, exchange call, email sending, authorization.
• Each entry was given a user identifier, order number, and the response code of the external service — these tie the incident to a specific action.
• Severity levels were configured: critical ones are always written, debug ones are enabled selectively for the duration of an investigation.
• Rotation was configured: the log stores entries for a given period and clears old ones, so it doesn't grow uncontrollably and doesn't overflow the disk.

What the result was

The cause of a failure is now found within minutes: the entire chain of events is pulled up by the order number — from the request to the response of the external system.

The share of undetected incidents has decreased: failures that previously went unnoticed are recorded in the log and get investigated. Repeat requests for the same problem have decreased — the engineer sees the cause immediately instead of piecing it together again.

How does a custom event type differ from a standard one?

A standard event type records the fact itself: "user logged in," "element changed," "order placed." That is enough to see that an action occurred, but not enough to understand why it led to a failure.

When an incident has already happened, the engineer opens the log and sees a line with no details — and then manual searching begins: who exactly, from which section, with what data, what happened before that.

A custom event type solves a different problem — it preserves context sufficient for investigation.

We describe not only the action but also the circumstances around it: the entity identifier, the values of key fields before and after the change, the request source, the link to a session or deal.

Such a record can be used as evidence: it reconstructs the chain of "what led to what" without reading code and without involving the developer who wrote the specific handler.

The difference shows up at the moment of analysis.

With a standard type, the engineer answers the question "what happened" and almost always hits a wall with "and why — unknown." With a custom one, they immediately see the event context and close the incident using the log: compare states, find the anomaly, test the hypothesis.

This shortens the path from signal to cause from hours of manual searching to a few minutes of reading records.

It is also important that custom types do not replace standard ones but complement them. The standard log remains the baseline — it shows the overall picture and anomalies in system behavior.

Custom records are connected where the cost of an error is high: payments, integrations with 1С, order synchronization, access rights.

We identify such points together with the client and configure the context so that it is sufficient for investigation, but the log does not grow with unnecessary noise.

That is precisely why configuring the 1С-Bitrix event log is not a matter of checking a box, but of designing which data goes into the record. A standard type provides the fact, a custom one provides the evidence base for analysis.

Common technical concerns when configuring the log

Separating writes from reads is the key point. Events are written to a buffer and flushed in batches rather than one request at a time to the database, so the write overhead stays within fractions of a millisecond per operation.

The main performance risk comes not from logging itself, but from synchronous writes to the main table and from reads without indexes — that is exactly what we separate into different contours during configuration.

What about personal data in the log?

By definition, the log records user actions, so it contains identifiers, addresses, and request parameters. We configure masking of sensitive fields at the write stage, restrict access to the log by role, and limit the retention period.

This removes the risk of leakage through the log itself and simplifies passing data protection audits.

We already have a log deployed — what should we do with it?

First, an audit: we look at the volume, retention depth, presence of indexes, and access rules. Then — migration without stopping the site: we move the history to a separate contour, introduce rotation and masking, and clean up duplicates and "noisy" event types. Already accumulated data is preserved, and rollback to the previous configuration remains possible.

How does this relate to security?

The log is primarily a tool for incident investigation: who, when, and what changed. We configure custom event types for critical operations, protect the log itself from modification, and maintain a separate contour for administrative actions. This way, investigation relies on reliable records rather than guesswork.

Let's discuss your event log task

An event log almost never comes up on its own — it comes up as a consequence: logs grow faster than the disk, rotation is configured "by eye," and the event you need at the moment of incident investigation isn't in the file.

To come back with an estimate and a plan rather than generalities, we need a snapshot of your current configuration — how event types are structured, where records are written, and what happens to them afterward.

Describe the task in your own words, and we'll clarify the details and come back with a configuration plan and timelines by stage. Below is what's useful to include with your description so the work estimate is accurate rather than "give or take a week."

• The current log volume and how fast it grows: how many records per day, over what period the file becomes unreadable.
• Which events are needed in the log: only errors and failures, or also administrator actions, catalog changes, order processing.
• How rotation is currently configured: by size, by time, manually, or not at all.
• What happens to archived records: deleted, moved to separate storage, exported to an external system.
• Who reads the log and how: a developer through an interface, the support team per regulations, external monitoring.
• Whether there are access separation requirements: so that a content administrator doesn't see technical events, and a contractor sees only their own perimeter.
• What failures have already occurred: lost records, disk overflow, inability to prove that a change took place.

From this a plan takes shape: we define a set of custom event types, configure severity levels and rotation rules, separate access, and verify that the necessary records survive cleanup and remain suitable for investigation. Describe your situation — we'll come back with an estimate and a work plan.