A foundation for boxed Bitrix24: logs, alerts, a 1C client and a security audit
The portal's custom layer had grown for years: about 20 home-grown loggers in 8 different directories, not a single alert, about 50 raw curl calls to 1C (the main one with no timeout), 21 hardcoded tokens and 7 inconsistent phone normalizers. Failures were reported by managers.
The portal drives sales every day — changes can only be targeted, with a backup of every file; production has drifted from git, so whole files cannot be deployed.
- Analysis of 454 PHP files: shared wrappers chosen by actual call counts, not by taste
- A unified JSONL logger with an end-to-end request id and personal-data masking; a critical error immediately goes out as an alert to Telegram and the portal chat, with deduplication
- A standard 1C client: timeouts, and retries only for idempotent requests — a repeated POST would create a second document in 1C
- A log viewer with cross-log search, a health endpoint for monitoring and rotation: the first run compressed 1,087 MB down to 30 MB
- Security audit: closed anonymous access to deal actions, restricted 1C intake to its addresses, removed files with tokens and personal data from public access
- More than 15 cron jobs and utilities switched to CLI-only, the webhook rotated, formula injection closed in CSV exports
Failures became visible the moment they happen, not after a complaint: a critical error arrives as an alert, and any request can be traced by request id. Everything the audit found was closed with targeted, backed-up deployments — with zero 5xx responses after them.
Related services and solutions
Bitrix24 D7: boxed development and stabilization
I work not only with interface settings, but at the level of the box, the code and internal APIs.
Business process automation
When employees transfer data manually, reconcile spreadsheets, lose requests or repeat the same actions — I turn the routine into code.