WPVivid Backup writes per-job logs and stores backup history through plugin-managed records in wp_options with files in wp-content/wpvividbackups. The plugin's history page shows recent jobs page by page, but trend views, destination filters, and per-job comparisons are limited because the page is built for inspection, not slicing. Migrations, restores, full backups, and incrementals all share the same list, and a 22-minute slow migration sits next to a 9-minute healthy Full with nothing distinguishing them visually.

SleekView reads the records WPVivid already writes and surfaces them as a real grid: started, action (Full backup, Incremental, Migration, Restore), destination (OneDrive, Amazon S3, Local), size, duration, outcome. The same data, with the addition of filtering and saved views. The Action column matters because WPVivid is one of the few backup plugins that also handles migrations as first-class jobs, and treating both as the same row type pollutes ops reporting unless you can filter them apart.

The duration trend is where this earns its keep. A migration that takes 22 minutes once is not a problem; the same migration creeping toward 30 minutes over six runs is. WPVivid's history page does not surface that drift. The grid does. A saved view sorted by duration with the last 14 days as the filter window catches a slow regression weeks before it breaks the schedule, and the click-through opens the original log file WPVivid already wrote.

WPVivid's strongest feature is that it does both backup and migration in one plugin, and that strength is also what makes its history hard to read. A migration is a one-shot operation that ships data to another site; a backup is a recurring operation that ships data to a destination for safekeeping. They share machinery and they share log format, but they answer different operational questions.

Healthy migrations are infrequent and fast. Healthy backups are frequent and consistent. Lumping them together hides the answer to both.

A migration buried in three weeks of nightly Fulls is hard to find when an editor asks how long the staging copy took yesterday. A nightly Full hidden among twenty migrations during a redesign sprint is hard to find when reliability asks whether last Sunday's backup ran. SleekView makes the distinction trivial by exposing the action type as a column.

Filter to Migration to see the redesign sprint, filter to Full backup to see the nightly schedule. Same plugin, same dataset, two different ops realities, finally separable.