Monitor services jobs and recovery readiness

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

Overview

System Health and Backup & Recovery provide complementary operational evidence. Readiness checks database access; worker heartbeat and queues show whether background work is being processed; recovery evidence shows whether artifacts have been created, verified and tested.

Purpose

Detect service degradation early and collect useful diagnostic information without exposing credentials or relying on a single green status.

Prerequisites

• Authorized access to Administration > System Health and the relevant recovery information.

• A named operator and a tested external alert route where required.

• For host diagnostics, approved Linux or Windows administration access.

Procedure

1. Review System Health for database, worker and storage status, queue failures, oldest due work and recent request metrics. Compare observations over time when diagnosing intermittent behavior.

2. Check both /api/health and /api/ready through the intended operational path. A liveness response does not establish database readiness, and readiness alone does not establish worker progress.

3. Review the worker heartbeat and active/failed queues. Correlate delayed activities, email, imports, automation and backups with worker status and due-work age.

4. Open Backup & Recovery Overview and compare last successful backup, last verified backup, last test restore, storage health and next scheduled backup. Resolve operational alerts using the specific artifact/job history.

5. On packaged Linux, use status, version, bounded logs and diagnose to gather release and host evidence. On native Windows, use Server Manager, the Windows service state and protected service/gateway logs.

6. Review disk growth, capacity headroom, service restarts and certificate renewal. On cloud hosts also review the infrastructure metrics appropriate to the instance/storage model.

7. Record the symptom, time, request/job identifier, release/schema identity and affected operation when escalating. Remove credentials, tokens, personal data and raw configuration from support material.

Bounded Linux package diagnostics

sudo zbix-crm status
sudo zbix-crm version
sudo zbix-crm logs --tail 100 api worker
sudo zbix-crm diagnose

Expected result

The operator can distinguish an unavailable API, failed database readiness, stalled worker, storage pressure and incomplete recovery evidence, and has a repeatable escalation record.

Important notes

• The Linux worker container health check uses a persisted running heartbeat with an age limit of 90 seconds. A container process alone does not prove useful work.

• System Health does not replace independent host/cloud monitoring or prove external email delivery.

• A configuration screen or healthy destination is not a successful backup restore test.

• Keep maintenance such as retention review, certificate renewal and recovery rehearsal on an owned operational schedule.

Troubleshooting

• For database readiness failure, inspect database/container service health and connectivity before restarting unrelated components.

• For a stale worker, check bounded worker logs, database availability and resource pressure. Review existing job state before resubmitting work.

• For repeated errors, preserve the relevant diagnostic window and escalate with exact status and IDs rather than screenshots containing secrets.

Related articles

• Plan capacity for CRM workloads

• Schedule recurring recovery points

• Verify a recovery point independently

• Plan network access DNS and HTTPS

• Plan recovery and rollback decisions