Versus Rewind
Estate time-travel for root-cause analysis — reconstruct a device's config at any past moment, diff two snapshots with detected drift overlaid (who changed it, under which change ticket), and read one merged timeline of config captures, drift, audit actions and monitor events.
When something breaks, the first question is always "what changed, and when?" Versus already holds the raw material — a config snapshot at every discovery import, detected drift, the audit log and monitor events — but it is spread across four screens. Rewind puts you at a moment in the past and lets you diff "when it worked" against "when it broke". Find it under Diagnostics → Rewind (administrator access).
Rewind is a read-only lens: no tables, no capture job, no write path. Every view is assembled at query time from records Versus already stores, so it works on day one of any estate that has run discovery, and it can never alter a device.
What it reads
| Source | Where it comes from | Timeline domain |
|---|---|---|
| Config snapshots | Taken at the end of every discovery import — the raw device config when a text backup exists, otherwise a vendor-agnostic serialisation of the device's virtual servers, pools, certificates and firewall rules. The last 10 per device are kept. | config |
| Detected drift | After each import the change detector diffs consecutive snapshots, correlates the diff against ServiceNow change requests that overlapped the discovery window, and records the operator from the device audit log when nothing matches. | drift — summary, actor, matched change number, status |
| Audit log | Platform actions — create, update, delete, toggle, upgrade, backup, login — with the user who performed them. | action |
| Container monitor events | Breaches raised by Container Monitor — node pressure, CrashLoopBackOff, unhealthy containers, LB↔VIP correlation — with cluster and incident number. | monitor |
Each source is read independently: if one is absent or empty, the others still render.
Config Diff
Pick a device — the picker lists every device with config history and its snapshot count — then tag two snapshots A (older) and B (newer). Each snapshot shows its capture time, age, line count and a short content hash. The page opens with A = oldest and B = newest so the full drift is visible immediately, and the diff is always oriented older → newer whichever you tag first.
The right-hand pane is a unified diff — added lines green, removed red, hunk headers cyan — with added/removed counts. Above it, any drift detected between the two capture times is overlaid as a banner: when it was detected, who made the change (from the device audit log), and either the matched change number or no change ticket. That is the difference between "a line changed" and "jdoe changed this, with no change ticket" — the sentence an RCA actually needs.
A worked example
python manage.py seed_rewind_demo builds the scenario in the screenshot on a Palo Alto firewall named rewind-edge-fw-01: a working config seven days ago (Allow-Checkout-API permits TCP 8443 from untrust), a breaking change two days ago (the rule flipped to deny and a broad Deny-Unknown rule inserted), a cosmetic login-banner change two hours ago, and one drift record attributed to jdoe with no change ticket. Open Rewind, keep the default A/B, and the diff reveals the flipped rule with the banner naming the actor. --clear removes the demo device.
Estate Timeline
The second tab merges all four sources into one newest-first feed. Each row carries the summary, its kind (config_captured, unauthorized_change, an audit action, or a monitor check key), the device, the actor, and both relative and absolute timestamps. Reading it around an incident's start time answers the second RCA question — what else happened in the estate?
Point in Time
The third tab reconstructs a device's config as of any moment: pick the device, set the date and time (or jump to one of its snapshots), and Rewind shows the latest snapshot taken at or before that moment, when it was captured, and when the config next changed — or tells you the history does not reach that far back and when the first snapshot was taken. It is the "what did this device look like at 02:14 when the alert fired?" question, answered without a diff.
The same reconstruction is available from the API (next_change_at, no_data_before). All endpoints are GET and require authentication.
| Endpoint | Parameters |
|---|---|
/api/rewind/devices/ | — (devices with history and snapshot counts) |
/api/rewind/snapshots/ | device_id (last 100 snapshots) |
/api/rewind/point-in-time/ | device_id, ts (ISO 8601) |
/api/rewind/diff/ | device_id, a, b (snapshot IDs) |
/api/rewind/timeline/ | optional since, until, device_id, limit (max 500) |
What it does not do
Rewind shows the past; it never pushes a past config back to a device — restoring anything remains a governed change through the workflow engine. Depth is bounded by what each source retains (10 snapshots per device, the audit log's own retention), and Rewind reads only the rows you can already see in Devices, the audit log and monitors.
Related
- Config Archaeology — the same history mined per object to decide whether it is safe to remove.
- Failover Readiness — config, certificate and route parity between HA members.
- Device management — the discovery imports that create snapshots.
- Audit logging — the platform actions that feed the timeline.
- Diagnostics AutoPilot — the war-room agent for when the timeline points at a cause.