Read System Health and verify service 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 provides administrator-visible evidence for database reachability, worker heartbeats, queue state, private storage, backup status and recent HTTP counters. Runtime identity reports the source commit, image identities and database migration when supplied by the installation. These checks describe different layers and must be interpreted together.

Purpose

Use the health page for routine checks and incident triage before attempting corrective service or data changes.

Prerequisites

• Administrator identity.

• The intended release and the time range of the incident.

Procedure

1. Open Administration > System Health and choose Refresh system health. Record the checked time and warnings in the private operations log.

2. Confirm database reachability, then examine worker last-seen and last-success times. The backend considers a running heartbeat healthy when it is no more than 90 seconds old.

3. Inspect queued and failed counts and the oldest due-work age for the affected operation. Open the corresponding job or activity history for details.

4. Review storage availability, writability and free capacity. Escalate a storage warning before uploads, imports or recovery work exhaust the volume.

5. Review runtime identity against the release plan. Treat unreported fields as unavailable evidence rather than proof of a match.

6. Inspect Backup & Recovery for artifact verification, isolated restore and destination evidence. A legacy receipt alone does not establish recoverability.

Expected result

The operator has a dated health assessment with specific follow-up actions for the affected component.

Screenshots and diagrams

SS-043 · System health dashboard. Demonstration capture, 28 October 2026. Select the image to enlarge.

Important notes

• GET /api/health is liveness; GET /api/ready checks database readiness. Neither alone proves background work or an external provider works.

• HTTP percentages are derived from bounded recent counters; absent request samples do not establish zero errors.

• Healthy backup status depends on several recorded prerequisites. Do not replace a degraded status with an assumption based on a file existing.

Troubleshooting

• The health page is denied: identity administration access is required.

• Database is reachable but jobs are delayed: investigate worker heartbeat, due work and operation-level history.

• Runtime identity is unreported: have the deployment owner reconcile the artifact and configuration privately.

Related articles

• Background processing and durable jobs

• Operational logging and support evidence

• Routine application maintenance checklist