Change Log

Nova PBX → Analytics → Change Log is the version history of your PBX configuration. Every time configuration is applied to your phone system, the platform records a commit: when it ran, who triggered it, whether it succeeded, exactly what changed, and a snapshot you can restore later.

This page is mostly diagnostic — most teams only open it when:

A saved change isn’t taking effect (look for a recent Failed entry and its error)
A greeting plays as silence even though the menu or queue looks right (look for Applied — audio missing)
They’re investigating an incident and need to know what changed, when
They’re auditing configuration history for change management
They need to roll back to a known-good version

Access requires the Manage PBX settings and devices permission — the same permission that gates PBX Settings. It covers both viewing this page and using Restore.

If you manage this organization as a partner, you can read the change log but not Restore from it: a restore is applied with your own organization’s permissions, which do not carry into a customer’s PBX.

Video
Screenshot

Watch on YouTube ↗

The staged-commit model

Saving a setting in the portal does not touch your live phone system immediately. Changes are staged:

You edit and save — extensions, queues, routes, IVRs, anything. The portal banner shows “You have unapplied changes.”
You click Apply Changes (or the platform auto-applies, depending on the surface). The platform pushes the whole staged set to your PBX engine — typically live within ~60 seconds.
The push is recorded here as one commit, with a content config hash and a snapshot of the configuration.

One commit can therefore bundle several edits made between applies. Commits are grouped by day, newest first, and each shows who saved the change (“by …”, or Automatic for system-initiated updates).

Statuses

Applied — live on your PBX.
Pending — queued or in flight. Persistent Pending (more than a few minutes) suggests the PBX agent is slow or down.
Applied — audio missing — your settings ARE live, but the push could not deliver one or more audio files (an IVR greeting, queue announcement or voicemail greeting). Callers hear silence where that recording should play. Re-upload the audio on the resource it belongs to and apply again. This is not a failed push: the configuration itself landed, so your PBX is running the new settings.
Failed — not applied; your PBX still runs the previous configuration. The error appears under the row. Transient failures (timeouts, connectivity) retry automatically — a Failed entry followed by an Applied one with the same config hash is normal.

Two extra badges: Restored marks a commit that was created by a rollback, and Checkpoint marks an automatic recovery point the platform captures just before a restore runs.

Reading a commit’s diff

Expand any row (chevron) to see What changed, grouped by area (Extensions, Call Queues, IVR Menus, …):

Added (green) — a new item was created
Removed (red) — an item was deleted
Modified (blue) — an existing item changed, with the old → new value per field

Older commits that predate version history show “Snapshot unavailable” — they can’t be diffed or restored. The earliest versioned commit shows “First recorded version.”

The expanded row also lists technical details — the full config hash (identical hashes = identical configurations; support uses it to verify a push arrived intact), the commit ID, sync time, and attempt count.

Restoring an earlier version

Every restorable commit has a Restore this version button in its expanded row.

What a restore does:

Shows a preview first — exactly which items would be added, updated, and removed compared to your current live configuration. Nothing changes until you confirm.
Applies only the differences. Unchanged settings are untouched.
Never touches data: your voicemail messages, call recordings, and call history are not part of configuration and are never altered by a restore.
Creates a new forward commit (plus an automatic Checkpoint of the pre-restore state). History is append-only — a restore is itself reversible by restoring the Checkpoint.

When a restore is blocked: if rolling back would delete an extension that still owns data the platform won’t silently destroy, the preview lists the blockers and the Restore button stays disabled. Remove those items manually, then restore. If the preview reports the version already matches your current configuration, there is nothing to do.

Retention

The page shows the most recent 50 commits. The platform retains configuration history beyond that for compliance — contact support if you need older records.