How to check which VICIdial version each server is running

The version column on the Server Versions page shows the exact VICIdial/astguiclient build string installed on each server in your cluster — your fastest way to catch a version mismatch before it causes hard-to-diagnose problems.

What the version string represents

VICIdial identifies each build with a revision marker — typically a date-based string followed by a short sequence number (for example: 240915-0830). This marker is baked into the astguiclient code during install. When you see it in the version column, you are reading the marker from whatever was installed on that specific server at its last upgrade.

In a single-server setup the version column is informational. In a multi-server cluster — a web/DB master with one or more Asterisk dialer nodes — every row must show the same string. The web server and the dialer servers speak a protocol between themselves, and that protocol is tightly coupled to the build version.

Why a version mismatch causes breakage

A partial upgrade — where the web/DB server is updated but one dialer node is missed, or vice versa — leaves the cluster running two different builds simultaneously. The failures that follow are typically subtle:

• A new field introduced in the database schema by the upgrade may not exist on the older node, causing silent failures when that node tries to read or write it.
• The Real-time report and the Whiteboard report pull data from all nodes. If one node is on a different version, its data may render incorrectly or cause display errors in the reports.
• Inter-server communication for features like call transfers, Agent login routing, and campaign assignment can silently fail or produce incorrect behavior when the nodes disagree on the protocol version.
• Errors often appear in unexpected places — not on the upgraded node but on the one that was missed — making the root cause hard to trace without checking versions first.

flowchart LR
  A["Server Versions page"]
  A --> B["Read version column for each row"]
  B --> C{"All rows match?"}
  C -->|Yes| D["Cluster is version-consistent"]
  C -->|No| E["Identify which node is different"]
  E --> F["Upgrade the lagging node"]
  F --> G["Reload page and verify match"]
  G --> D

How to check and what to do when they differ

Open the Server Versions page and scan the version column from top to bottom. In a healthy cluster every cell shows the same string. If any row differs, note which server it is (the server name column tells you), then complete the upgrade on that node. After the upgrade finishes, reload the page and confirm all rows now match before resuming normal dialing.

The version check should be your first step any time you see unexplained errors after a planned maintenance window. Most operators also check it immediately after an upgrade to confirm the procedure was applied to every node in the cluster.

Pairing version checks with other health signals

Version alignment is one column in a multi-column picture. While you are on the page, also check load and disk. For a time-series view of how each server is performing across a full shift, the VICIdial system load explained guide covers what the load number actually measures and when it signals trouble.

For a complete view of what to watch across your cluster and how often, see the full guide to monitoring VICIdial server health and capacity.

Prefer a setup where upgrades are handled for you and every node is always on the same version? Start a VICIfast trial and get a managed VICIdial server running in under 40 seconds, updated and version-consistent from day one.