Keep the backup tools you already use. See their reported results, follow up on missing signals and give clients a dated record. Here is how each part works.
When you manage several WordPress websites, checking each backup plugin separately takes time. BackupTool brings the reported activity into one private workspace, highlights signals that need attention and keeps the follow-up readable.
Your existing backup software still creates and stores the files. You keep responsibility for its schedule, storage settings and recovery process.
You need a supported backup plugin on that site and permission to install the BackupTool Connector. A cloud connection is optional.
Enter the site’s HTTPS address and a name you will recognize. Choose how often you expect a backup report and how much extra delay is acceptable.
Install the companion WordPress plugin on the site you want to monitor. Copy the workspace’s event endpoint, site identifier and one-time key into its settings. Each site has its own key; keep it private.
Send a connection heartbeat to check delivery. Next, run a real backup in your existing backup plugin. A heartbeat establishes contact; the job report establishes what that plugin reported.
Before the first backup report arrives, the reporting window starts when you add the site. Later windows start from the reported completion time. These are elapsed-time expectations, not a replacement for the schedule in your backup plugin.
UpdraftPlus: completion and warning reports through its completion hook. Failure reporting depends on the plugin producing its report hook.
Backuply: future successful-completion timestamps. Its adapter does not capture warnings, failures or backups made before pairing.
WPvivid: success and terminal-failure hooks, inspected against official version 0.9.136. Legacy errors marked for automatic resume are excluded from final-failure reports.
Plugin editions and versions can behave differently. Confirm a real reported job with your own setup. If your plugin is unsupported, its backups can still run, but BackupTool cannot automatically infer their results.
Try an interval and grace period. This simplified model measures elapsed time from a reported backup, with no calendar scheduling.
20 hours have elapsed. The report becomes overdue after 25 hours.
The hub evaluates the deadline when monitoring runs. A missed report may reflect a delayed job, a connector issue or another cause.
BackupTool receives signed metadata. Your backup software owns the archive transfer.
A supported connector adapter reads the backup plugin’s job result. Backup files stay with your backup software and storage provider.
HTTPS and HMAC signatures protect event delivery. Failed deliveries are queued for another attempt.
The hub records the job observation and checks timing expectations. Email notifications require opt-in and working mail delivery.
A missing report is a reason to investigate. It can mean a delayed backup, a stopped job, a disconnected connector or another delivery problem.
The incident desk records a missed signal, reported failure or warning. Acknowledge it, start investigating, add a note or set a reminder to review it in one hour, one day or one week.
When a successful report resumes, the incident shows that change. You review the evidence and explicitly resolve it with an explanation; a new report does not silently close the investigation.
Observation emails use your configured recipient and email opt-in. Optional queued follow-up adds repeat alerts for unacknowledged incidents, UTC quiet hours and a temporary maintenance window. You can also enable a daily unresolved-incident digest.
Optional Slack delivery sends a site name, signal, timestamps and workspace link to your configured incoming webhook. Investigation notes and recovery records stay out of those Slack messages.
Connect your own Google Drive, Amazon S3 or Backblaze B2 access to request metadata for one exact archive. You can use job monitoring without connecting storage.
An archive is the backup file produced by your backup software. Metadata is information about that file, such as its reported size and modification time, rather than its contents.
Use Google’s file chooser to select a Drive file, or configure an exact S3 or B2 object reference with the required provider access. Public file sharing is unnecessary.
Choose “Check metadata now.” The history records the time, provider, object reference, result and reported size where available. “Present” means metadata was accessible at that time.
Optionally authorize checks every six hours, day or week for that saved object. You can flag provider-reported file age or a size drop of more than 20% compared with the same object’s previous check.
An older archive can still exist. An unchanged file will naturally age. Use presence-only checks for an immutable backup; enable an age limit only when you expect that exact file to be updated. Selecting a different object pauses the old schedule until you consent again.
These checks do not automatically find your newest backup, open archive contents or prove recovery. Google’s selected-file permission can allow broader operations on selected files, but BackupTool’s implementation requests metadata only. Provider requests may incur provider charges.
A successful backup report and a file being present do not establish that a website can be restored. Recovery is a separate question.
If you perform a restore test outside BackupTool, enter its date, outcome, archive reference, environment, checks and limitations in Recovery records. Keep the account of the test specific enough for someone else to understand.
BackupTool stores your record. It does not restore websites or independently verify what you entered. If no test has been recorded, the report says so.
Choose a site and a UTC date range. Job results, connector contact, archive checks and customer-recorded tests appear as distinct sections.
Choose which sections to display, then print or save the report as PDF in your browser. Excluding a section from this view does not delete the workspace’s records.
Select owned sites and a brand name, then opt into a weekly or monthly HTML summary sent to your configured recipient. Weekly summaries cover the previous week; monthly summaries cover the previous month. PDF attachments are not generated.
Reports describe retained records, not every backup that may have run. Job metadata is retained for 90 days; archive history keeps the latest 30 manual and scheduled checks. Customer-recorded tests remain until the site is removed.
A report can show a job’s reported success while also showing that no archive check or restore test was recorded. Keeping those facts separate makes the record useful when a client asks what was checked.
Daily review brings current job signals, connector-contact concerns and enabled archive-check flags into a portfolio view. Follow each prompt back to its site evidence.
Start with sites that need attention. Read what happened and when, inspect the source tool where needed, then keep your investigation in the incident desk. The workspace helps you organize the work; it does not diagnose every cause automatically.
Download an owned-site HTML handover with current reporting expectations and retained job, contact, archive, recovery and incident records. Open it locally and print or save it as PDF.
The demonstration uses sample data. Availability of signup, payments and optional features is controlled separately.
Each account owns its monitoring records. Shared team assignment is not included in this release. Configure only sites and storage you are authorized to access.
Cloud checks, queued follow-up, Slack and scheduled reports require configuration and opt-in. Optional AI drafts, where enabled by the operator, are customer-reviewed assistance rather than verified findings.
The trial lasts 7 days and does not create a paid subscription. Public signup and real payments remain closed during development review. A paid subscription requires an explicit checkout when live sales open.
The connector queues individual metadata events and retries delivery. A missing signal can have several causes; review the client plugin logs and connection.
No. Backup archives follow the route configured in your backup software. Only monitoring metadata is sent to the hub.
Explore a labelled sample portfolio before connecting a real site.