Technical support for an app in the Bitrix24 Marketplace

Application technical support: what breaks after release

An application in the catalog lives in someone else's environment: the platform updates on its own schedule, and external services change response formats without warning.

Therefore, some failures are not visible either in tests or on the staging environment — they manifest at the client, on their data and settings. Below are typical points from which application technical support begins.

First — silent errors after a platform update. A call that previously returned data now returns an empty response or a warning instead of an exception: the integration formally works, but some fields arrive empty. Regression testing does not catch this if checks are based only on response codes.

Second — discrepancies in data exchange. Duplicate contacts and deals, mismatched statuses, lost line items in documents: externally everything is alive, but the numbers in reports do not add up, and the business loses trust in the system before engineers find the cause. Here, checksum reconciliation and reprocessing of the queue help, not point fixes.

Third — requests that cannot be reproduced by the developer. Different permissions, non-standard portal setup, old records in the database: our scenario passes, the client's fails.

The investigation proceeds by error logs and the event chronology of the specific portal — otherwise the flow of user requests grows, and the cause remains the same.

We analyze how this is closed: response regulations, on-call duty for requests, and monitoring that notices degradation before mass complaints.

What systematic support provides: effect in numbers

Systematic support changes the metric itself: response time to a request drops from hours to minutes during the working window.

Marketplace requests, client emails, and monitoring system alerts end up in a single queue with assigned priorities — they are handled by an on-call engineer, not by a developer on a leftover basis between tasks.

The number of requests decreases not through persuasion, but through eliminating causes. Recurring failures are investigated to the root cause, typical questions are closed with interface fixes and an updated instruction, not with another reply in a chat.

Keeping the share of repeat requests for the same problem at a few percent is a normal goal, and it is achievable when every incident ends with a change rather than with closing a ticket.

Service recovery time is determined not by the speed of the fix, but by how quickly we understand what exactly broke.

Complete operation logs, metrics for critical scenarios, a proven procedure for rolling back to the previous build, and verifiable backups move an incident from the mode of finding someone to blame into the mode of executing a known sequence of actions.

A separate effect of support — an entire class of failures goes away. Mass payment failures, data loss during an update, incompatibility with a new platform version are intercepted during planned work and on the test environment, not on live clients.

Instead of sudden "application unavailable," there remain local errors for some users, which are handled in the normal course of work.

Work formats in Bitrix24 Marketplace: improvements and on-call duty

The work format is chosen not by the number of tasks, but by the cost of downtime and the frequency of platform changes. Bitrix24 updates regularly: the core changes, the rules for moderating updates in the Marketplace change, and the behavior of external integrations changes.

If the application is not checked after such changes, installations begin to fail for some users — and you learn about it from reviews, not from the team.

Below are three modes that are actually chosen between. They differ in response regulations, depth of involvement in support, and how the scope of work is planned.

The modes are not mutually exclusive: usually they start with a one-off improvement, and move to support when the application becomes overgrown with integrations.

The transition between formats is discussed separately — the scope of work and regulations are fixed anew, without rebuilding the entire project.

How the support regulations are built after handover

Handing over the application is not the finale of the project, but the point after which work quality is determined by the support regulations.

Without them, requests are handled ad hoc, the cause of a failure is not found, and the next platform update becomes a risk for the working portal. We build support as a sequence of implementation stages — from audit to documentation that any engineer on the team can work from.

1. State audit. We capture the current picture: which handlers, agents, permissions, and external dependencies are involved, and where errors accumulate.
2. Log audit. We analyze the history of requests and records — this reveals recurring failures and scenarios that break during an update.
3. Dependency map. We record connections with platform modules and portal objects: when one node changes, it is clear what to check.
4. Monitoring setup. Errors, installation failures, and spikes in requests go into notifications — a failure is visible before a user writes about it.
5. Testing on the test environment. We run platform updates and typical scenarios separately from the working portal so that the release does not affect live data.
6. Documentation handover. The application map, change log, diagnostics and rollback procedures remain with the client, not only with us.

Exchange schemes, documentation, and response rules

Application support should not rest on the knowledge of specific people who wrote the code yesterday.

As a result of the work, you retain a set of artifacts that allow the task to be handed over to another team, the integration to be expanded, or the Marketplace review to be passed without restoring context from scratch. Everything is stored in your repository and updated with every change to the environment.

• Integration map — which external systems exchange data with the application, for which entities, and in which direction; with notes on where the environment is critical and where the exchange happens in the background and can wait.
• Data exchange schemes — the sequence of calls and events, retry and idempotency points; they show what will happen on redelivery or a connection break in the middle of an operation.
• Access rules — a matrix of roles and service accounts: who is allowed which methods and data areas, where rate limits are set, and how access is granted to a new engineer.
• Response regulations — incident levels, time to take into work, escalation procedure, and the conditions under which we join the investigation, and which cases are closed by your support service.
• Support service instructions — typical requests with ready-made scenarios: what to check in the interface, what data to collect, and at what point to pass it to an engineer.
• Release and rollback procedure — how an update is rolled out, where a backup is taken, and within what timeframe the environment returns to the previous working configuration.
• Change log — what was changed in the configuration and why, linked to requests: in six months you won't have to guess where a non-standard setting came from.

Artifacts are written for your environment, not from a template: schemes are verified against real calls, and the regulations — against your shifts and scope of responsibility. During the task discussion, we will determine which set is needed specifically for you.

Case study: how support eliminated recurring failures

An application in the Bitrix24 Marketplace with an active installation base lived on on-call support: requests were handled ad hoc, and there was no unified picture of failures.

A spike in errors after a platform update was noticed from users — some installations silently lost connection with an external service, and the owner found out about it last.

The share of repeat requests held at around 40%: the same error returned a few days later under a different description.

What was changed

We consolidated the failure log across all installations and linked it to the application version history — it became clear which update and which method call caused the growth in errors.

Alerts were configured for deviation from the usual level of requests, not for a single error: a one-off failure does not wake up the on-call engineer, a series does. Incident investigation was assigned to an engineer who knows the module, not to whoever became free first.

What changed

The share of repeat requests fell from 40% to 8% — the cause was closed in a release, not answered with a template email. Average recovery time after a failure decreased from several hours to half an hour: diagnostics begin with the log, not with correspondence with the user.

There are no more unnoticed failures that no client reported — they are detected by anomaly alerts. Support stopped being reactive: the team sees degradation before it reaches installations.

What to do if the service is already published without monitoring?

The service is already published, installations are coming in, reviews are accumulating — and that is not a reason to rewrite the code.

The absence of monitoring means that you learn about a failure from a client email or a drop in installations, that is, with a delay of hours and days. The first step is a reverse audit: we look at what actually works in production and which events pass through Bitrix24.

The audit result is an inventory of failure points: event handlers, background agents and the task queue, access token lifetime, calls to external systems, platform limits on request rate and export volume.

We assign each point a class: degradation, a silent error without a crash, or a complete failure of the installation scenario.

We connect monitoring without stopping the service.

At first, read-only: we collect metrics from logs and system events, changing nothing in the working environment, and for two to three weeks we gather a baseline — how many installations and launches per day, processing time, share of authorization errors. This baseline shows where the norm is and where there is a deviation.

Next, thresholds and alerts to the on-call engineer — not for "down or not down," but for degradation: queue growth, recurring token failures, a discrepancy between the number of installations and active licenses.

Plus checks along user paths: installation, first launch, payment scenario, exchange with the accounting system.

If some nodes are already broken, we fix them before enabling alerts — otherwise the signals will drown in noise. Describe what is published and how you currently learn about failures: we will return with an audit plan and the procedure for connecting monitoring.

Doubts and questions we resolve before starting work

Technical objections surface already during the process, when rework costs more. We resolve these frequent questions before the start: platform compatibility, access to the working environment, response times, and handover of the service from another team.

What access to the working environment is needed?

A separate account with permissions only for the required environment and access to the repository. We do not copy production data — diagnostics are performed on an anonymized copy, and access is closed upon completion of work.

How quickly do you respond to a failure?

We take a critical failure into work immediately, without a queue; regular requests — on the same working day. We determine priority by impact on users: complete unavailability, partial failure, cosmetic issues.

We are handing over an application from another team — will you take it?

It is feasible if there is access to the code and a test portal. First we build a dependency map and failure points, then close them with regulations. Without documentation, onboarding takes longer, but the work is not blocked.

Let's discuss the task: what is needed for an estimate and work plan

To have the task discussion end with a work estimate rather than a series of clarifying emails, it is enough to send the source data in one message.

When there are reproduction steps and logs for the failure period, the estimate is assembled in one pass — without logs, a noticeable part of the time goes to diagnostics rather than planning.

What to attach to the request:

• Failure description: sequence of actions, expected and actual result, time and user or portal identifier.
• Frequency of occurrence: constant error, rare cases, only under load, or in some clients — this immediately separates an application defect from the specifics of the portal environment.
• Application and portal logs for the failure window: error text, trace, response codes from external services.
• Configuration: application composition, active event handlers, external integrations, and data exchange with the accounting system.
• Access for the audit: test portal and application copy, repository or build, application server, access to logs. Send credentials via a secure channel and with a limited term — after the investigation, we close access.
• Expected result and acceptance criterion: what we consider fixed and which scenarios should not suffer during the fix.
• Constraints: window for work, requirements for preserving user data, and for rolling back to the previous version.

Next, we return with a work estimate and work plan: stages, the procedure for rolling out the update to the Marketplace, checks before publication, and the rollback scheme.

Describe the task in any convenient format — we will reply with what data is missing for an accurate estimate.