WP Time Capsule's incremental approach changes the backup question. Where most plugins write a single full archive per run, Time Capsule tracks every file and database change as a separate event, with cloud-side deduplication keeping storage costs predictable. Those events live in dedicated tables (wptc_processed_files, wptc_processed_dbtables, wptc_backup_history) which is what makes the incremental model work efficiently at the storage layer.

SleekView reads those tables directly. The processed-files view surfaces every file change captured by the most recent backup run, with filename, byte delta, and content hash visible as columns. The processed-dbtables view does the same for database rows. The backup-history view ties both together with run timestamp, total event count, and the linked remote destination.

For agencies running Time Capsule across many client sites, that audit trail becomes the missing portfolio dashboard. Confirm every site has a recent successful run, audit the file-change volume to spot suspicious activity, and verify cloud-side dedup is actually saving the storage the plugin promises.

Incremental backups change the storage math, but they also change the audit math in the opposite direction. A traditional full-backup plugin produces one event per run, easy to read in a list. An incremental plugin produces thousands of events per run, distributed across file and database change tables, which means the audit trail is richer but only useful if it's queryable.

WP Time Capsule's wptc_ tables are well-designed for that audit but the default plugin UI surfaces them through summary graphs rather than sortable rows. SleekView reads the tables directly with their indexes intact, which makes per-file change investigations viable across thirty days of incremental history. Security teams gain a forensic surface for investigating compromises.

Backup ops gain anomaly detection across the portfolio. Finance gains real dedup-savings numbers to defend the plugin spend. Each of those uses depends on the audit being queryable rather than aggregated, which the underlying tables already support.