SleekView for Jetpack Backup
Jetpack Backup writes per-run summaries back to the source site even though the archives ship to WordPress.com. SleekView reads those summaries and renders them as one filterable grid where restore points are queryable locally.
♾️ Lifetime License available
Restore points belong in WP Admin too
Jetpack Backup pushes restore points to WordPress.com on a real-time schedule and writes per-run summaries back to the source site in wp_options under the jetpack_ prefix. The full restore-point browser lives on wordpress.com/backup; the local dashboard shows only the most recent state. For agencies running Jetpack Backup across dozens of client sites, that means logging into wordpress.com every time someone asks how Tuesday's restore point looked.
SleekView reads the local wp_options summaries Jetpack writes and renders them as a real WP Admin grid. Columns become the things you care about during a reliability audit: started, scope (Full, Real-time, Database), size, duration, outcome, restore point ID. Filters and saved views replace the trip to wordpress.com for the most common questions: did backups run, were any slow, did any silently fail to ship.
The restore point ID column matters because Jetpack identifies each backup by an opaque ID that the wordpress.com side uses to scope the actual archive. Surfacing that ID locally means an ops engineer can copy the ID from the grid, paste it into a wordpress.com support conversation, and skip three clicks of explanation. The grid becomes the local index for the remote archive.
Workflow
From Jetpack restore points to a local audit grid
Read summary records
wp_options entries Jetpack Backup writes under its prefix after each restore point. No wordpress.com credentials needed for the grid itself.
Surface the restore point ID
Save the failure inbox
Drill into wordpress.com
Sample columns
Jetpack restore points
wp_options entries under the jetpack_ prefix that summarise each restore point
| Array | Array | Array | Array | Array | Array |
|---|---|---|---|---|---|
| Array | Array | Array | Array | Array | Array |
| Array | Array | Array | Array | Array | Array |
| Array | Array | Array | Array | Array | Array |
| Array | Array | Array | Array | Array | Array |
Comparison
Jetpack Backup admin vs SleekView
Jetpack Backup
- Restore point browser lives on wordpress.com
- Local dashboard shows only the most recent state
- Restore point IDs are not easily copyable from .com
- Hard to spot a real-time push that shipped zero bytes
- No saved view for failed restore points in the last week
SleekView
- One row per restore point on the source site
- Filter by scope to separate Real-time from Full
- Saved view for failed pushes in the last 7 days
- Restore point ID surfaced as a copyable column
- Click through to wordpress.com when deep detail is needed
Features
What SleekView gives you for Jetpack Backup
Local-first audit trail
Jetpack Backup writes summaries back to wp_options on every run. The grid reads them locally, so the trip to wordpress.com only happens when the deep restore UI is needed.
Scope filtering
Filter by scope to see Real-time pushes separately from nightly Full restore points. Reports stop blurring two cadences into one stack.
Failure inbox
Failed and Slow pushes stack at the top of a saved view until someone triages them. A 0 MB real-time push stops being silent.
Audience
For agencies, hosts, and ops
Site reliability
Confirm restore points across nightly Fulls and Real-time pushes are healthy this week. Group by scope and outcome to spot the gaps.
Agencies
Bring Jetpack Backup health into the same WP Admin you already use for client work. One grid per client, no per-site trip to wordpress.com to answer ops questions.
On-call engineers
When a restore is needed, find the last successful Full in seconds and copy its restore point ID into the wordpress.com restore flow.
The bigger picture
Why local restore point history matters even when archives are remote
Jetpack Backup ships archives to wordpress.com because that is the safest place for them: a separate infrastructure from the source site, with managed retention and a restore flow that does not depend on the source site being reachable. The trade-off is that the long-form history of every restore point lives on .com, which is the right place for the archive but the wrong place for a portfolio question like which sites had a slow Full last week. Agencies running Jetpack Backup across dozens of client sites need that question answered without logging into .com dozens of times.
SleekView reads the local wp_options summaries Jetpack writes back to each source site and renders them as one filterable grid. The .com side keeps the archive and the restore flow, which is where they belong; WP Admin gets the audit trail it needs. The two halves complement each other instead of asking the user to choose.
Questions
Common questions about SleekView for Jetpack Backup
No. Jetpack Backup owns the schedule, the real-time push hook, and the archive build on wordpress.com. SleekView reads the per-run summaries Jetpack writes back to wp_options on the source site. The backup plugin stays canonical; the observability layer is read-only.
From the wp_options entries Jetpack Backup writes under the jetpack_ prefix after each restore point. The archive itself lives on wordpress.com; only the summary metadata is local.
Yes. Restores run through wordpress.com because that is where the archive lives. The grid surfaces the restore point ID so the .com restore flow takes one click instead of three; the actual restore step is still on .com.
Jetpack Backup is a paid feature, so the records the grid reads only exist if Jetpack Backup is active and licensed. Without it, the wp_options summary rows are not written and the grid is empty.
Jetpack Backup is per-site, and SleekView mirrors that scoping. Each site has its own restore point history and its own SleekView grid. Network admins switch sites the standard way for per-site reporting.
None. SleekView paginates and queries on demand, and the wp_options summaries Jetpack writes are small even on sites with real-time backups running for a year. Queries finish in well under a second on typical hosting.
Partially. If the push fails before Jetpack writes a summary back, the row is missing rather than red. Most failures still produce a summary record marked as failed, which the grid surfaces; total handshake failures are visible as gaps in the timeline.
No. SleekView reads only the local wp_options summaries Jetpack writes, never the credentials Jetpack uses to authenticate against wordpress.com. Credential management stays in Jetpack's connection settings, where it belongs.
Pricing
More than 1000+
happy customers
Explore our flexible licensing options tailored to your needs. Upgrade your license anytime to access more features, or opt for a lifetime license for ongoing value, including lifetime updates and lifetime support. Our hassle-free upgrade process ensures that our platform can grow with you, starting from whichever plan you choose.
Lifetime ♾️
Most popular
EUR
once
- Unlimited websites
- Lifetime updates
- Lifetime support
...or get the Bundle Deal
and save €250 🎁
The Bundle (unlimited sites)
Pay once, own it forever
Elevate your WordPress site with our exclusive plugin bundle that includes all of our premium plugins in one package. Enjoy lifetime updates and lifetime support. Save significantly compared to buying plugins individually.
What’s included
-
SleekAI
-
SleekByte
-
SleekMotion
-
SleekPixel
-
SleekRank
-
SleekView
€749
Continue to checkoutBrowse more
- Woocommerce Bulk Edit Products
- Woocommerce Gift Registry
- Order Status Manager
- Yith Woocommerce Affiliates
- Square For Woocommerce
- Woocommerce Product Table
- Samcart Bridge
- Woocommerce Multilingual Currency
- Woocommerce Fast Checkout
- Woocommerce Shipping Multiple Addresses
- Woocommerce Color Swatches
- Woocommerce Product Add Ons
- Woocommerce Paystack
- Woocommerce Aftership
- Thrivecart Funnels