Health checks, background services and workers

Prerequisites and authority

Assign an operator and an authorized technical owner. Data-replacing recovery and updates require a maintenance window, preserved recovery point and known target.

Check services and worker progress

Inspect Docker/Compose state, API health and actual background runs separately. A process can be running while failing every job, and a healthy API can coexist with a stopped subscription worker.

1. Review System Operations for recent failures, long-running work and processed counts.
2. Compare each worker's last successful run with its configured interval.
3. Check relevant service logs around the failure time.
4. Identify failed dependencies such as MySQL, router reachability, provider connectivity or storage.
5. Correct the dependency or escalate the code failure.
6. Retry supported idempotent work when safe, then verify scheduled execution resumes.

Do not call a worker unhealthy solely because it has no work to process. Determine whether its heartbeat/run cadence is current and whether eligible records are accumulating.

Bot runtime health and Telegram configuration are separate. A running bot with no configured Telegram token can report runtime healthy and configuration not_configured; that configuration state alone does not make the deployment unhealthy. Docker can initially report starting while its health probe settles. Recheck after startup instead of treating that temporary state as a final failure. An actual runtime failure still requires investigation. Telegram must be configured before customers can use its interface.

The integration synchronization worker skips license-blocked cycles without reporting a connector failure or a false recovery. Genuine connector failures remain errors; a skipped cycle is not evidence of successful synchronization.

Background worker and operations reference lists the source-declared services. Exact interval values belong to supported runtime configuration, not historical development timings. Record last start/end, trigger, status, succeeded/failed counts and error where available.

When restarting a worker, capture evidence and avoid duplicate parallel runs. Some jobs have lock/idempotency mechanisms, but these must be verified for each operation. Do not use a broad Run All as an unexplained cure.

After repair, check the business outcome: activation, accounting, delivery or backup. Container status alone is not acceptance.

Related guides

Related guides: Back up BryanNet and validate backups, Restore BryanNet safely, Product updates, compatibility and rollback, Daily weekly and monthly operator checklists.