WP Time Machine is the long-running remote-backup plugin that ships a WordPress archive to Dropbox, Amazon S3, or FTP on a schedule. Its admin screen has always been functional rather than analytical: it tells you the last run status, lists configured destinations, and offers a manual trigger. That is enough on day one. By month six the install has hundreds of runs across two or three remotes, and the question 'is the Dropbox push still healthy?' takes more clicking than the data justifies.

SleekView reads the same wp_options run entries WP Time Machine writes for each push and renders them as a grid. Each row carries the started_at timestamp, the destination (Dropbox, Amazon S3, or FTP), the archive size, the duration, the outcome, and any error code the remote returned. A 1.2 GB Dropbox push sitting next to a Failed FTP push that returned an authentication error tells the ops engineer in one glance which remote target needs attention.

The destination filter is the most useful column on a multi-remote install. Filter to destination equals FTP for the last fourteen days and the grid becomes a focused audit of one remote, with each authentication failure visible as a red row instead of buried in a per-run log file.

Plugins that ship backups off-site have the strongest case for a real visibility layer over their own outputs. The whole point of remote backup is that the recovery copy is somewhere the WordPress install cannot reach if WordPress is on fire. That guarantee only holds if the remote is actually receiving the uploads.

WP Time Machine's status line answers 'did the last push work?' and is silent on 'has Dropbox accepted every push for the last six weeks?' SleekView answers the second question without changing how the plugin operates. Same run log, same remotes, one sortable grid that turns a six-week run of pushes into a queryable record instead of a single status string.