Background processing and durable jobs

Product Zbix CRM · Version 1.2.0 · Source reviewed · Reviewed 28 October 2026
Audience Administrators and implementation teams · Deployment Release specific self hosted

Overview

Zbix CRM runs a separate worker process for scheduled actions, background imports, email, calendar writes, mailbox synchronization, mock webhooks, managed backup work and attachment scanning. PostgreSQL stores job state and execution coordination. The worker performs bounded work in successive cycles and publishes a persisted heartbeat. A browser request that queues work does not mean the work has finished.

Purpose

Use this article to follow scheduled operations and to distinguish a queue delay from a completed or failed business operation.

Prerequisites

• Administrator access to System Health or permission to view the relevant operation history.

• The job, import, communication or automation record involved.

Procedure

1. Open the operation record and note its state, scheduled time, latest attempt and safe error. Confirm whether the operation is due.

2. Open System Health and compare worker heartbeat age with the queue counts and oldest due-work age. A healthy heartbeat is recent and reports running.

3. Check the initiating user is active and still has the permissions and related-record visibility required by the operation. Workers re-evaluate authority.

4. Use the operation-specific cancel or retry control only after reviewing its semantics. Import cancellation preserves completed batches; uncertain external sends require provider-side review.

5. After resolution, refresh the record and verify a persisted terminal outcome or execution receipt, not only an empty queue count.

Expected result

The operator can explain whether work is waiting, retrying, completed, cancelled or failed, and verify the effect independently of the initiating request.

Screenshots and diagrams

Important notes

• The worker usually waits two seconds when idle and retries its outer cycle after five seconds on a cycle failure. These are implementation intervals, not delivery-time guarantees.

• Hourly maintenance handles deleted/orphaned attachment cleanup and expired backup leases.

• Worker restart is designed around durable state. It does not justify repeatedly submitting an external action whose outcome is uncertain.

• Different job families use their own locking and retry rules; there is no universal retry policy for every queue.

Troubleshooting

• Due jobs accumulate with a stale heartbeat: investigate the worker service and database connection.

• One operation remains blocked while others progress: inspect that operation’s policy, actor permissions and execution history.

Related articles

• Read System Health and verify service readiness

• Operational logging and support evidence

• Troubleshoot queued failed or uncertain email

• Troubleshoot import validation and execution