From installation
to your first job report.
Install the hub, pair your client sites and verify the observations.
Instructions, expected results and checks for each connection.
Install the website hub
Upload the BackupTool Dispatch ZIP through WordPress → Plugins → Add Plugin → Upload Plugin, then activate it. Open the BackupTool menu to review development settings. WordPress 6.6 or newer and PHP 8.1 or newer are required.
Maintenance is enabled initially. Administrators can preview the developing pages. Select “Use Dispatch as your homepage” to set the front page. Turning it off restores the previously recorded front-page settings.
Dispatch
Plugins → Add Plugin → Upload Plugin
Pair the client connector
Open the client workspace and add a site using its public HTTPS address. Save the one-time site identifier and site key, together with the hub event endpoint. Download Connector 0.1.3 from the workspace Setup guide. Install it on that client’s WordPress installation.
Copy the three values into the connector settings and enable delivery. Each site uses its own key. If a key is lost, rotate it in site details and update the client connector. The former key will stop working.
- Event endpoint
- Where signed reports are sent
- Site identifier
- Which site owns the report
- Site key
- •••••••• Private one-time secret
Save the connector settings and enable delivery.
SIGNED CONTACT → HUBKeep the key private. A heartbeat proves contact; wait for a real backup-job report to establish completion.
Set an interval and grace period
Choose how often you expect a backup report and how much delay is acceptable. The first interval starts at site creation; subsequent intervals start from the reported completion time. Calendar-based daily time windows are not supported in this release.
A heartbeat shows that the connector contacted the hub. It does not establish backup completion. A missing signal can mean a failed job, a disconnected connector or a delay; investigate the cause in the backup software.
Example: a report at 03:00 UTC with a 24-hour interval and 60-minute grace becomes overdue after 04:00 UTC the next day, when monitoring next assesses the site.
This calculator is an illustration, not a saved setting. Connector contact does not restart the backup reporting window.
Schedule independent checks
Run this installation’s WordPress cron every five minutes from your hosting scheduler. The platform control centre displays a command using the current installation path and the last recorded check. Visitor-triggered WordPress cron alone cannot guarantee timely monitoring on a quiet website.
The workspace also provides “Run monitoring checks” for an immediate account-specific check. Email alerts are opt-in under workspace settings. Verify real mail delivery with your hosting configuration before relying on notifications.
Assess expected job intervals even when nobody visits the website.
Check the workspace scheduler evidence. A manual browser check does not prove hosting CLI execution.
Verify a real backup report
Connector 0.1.9 includes UpdraftPlus, Backuply and WPvivid adapters. Backuply reports future successful-completion timestamps only; warnings and failures are not captured by that adapter. Run a real backup on a connected client installation, then confirm that its reported result appears in the client workspace. Completion and warning reports come from UpdraftPlus’s completion hook.
Failure reporting depends on UpdraftPlus generating its report hook; overdue monitoring is a separate observation. A reported successful job is not an archive verification or a restore test. Record customer-performed restore outcomes separately. Test the actual plugin version and storage configuration you use.
- 01What ran?
The backup plugin reports its job result through a supported adapter.
- 02What was found?
A separate manual provider check records metadata for the expected object.
- 03What was tested?
The customer records a performed restore test, its checks and its limitations.
Three evidence types. Neither reported completion nor metadata availability proves full-site recovery.
Check one expected archive
Open Archive checks in the workspace and select a site. For S3, enter a region, bucket and exact object key with a restricted access key. For B2, enter an exact file ID and restricted application key. Drive requires the operator’s Google OAuth application and your consent to metadata-only access.
Save credentials, then explicitly run a check. No archive content is downloaded. Each outcome is recorded separately in provider history and reports. Removing stored access does not revoke the provider key or Google grant; revoke these with the provider.
Exact object / file referenceRequires your configured provider access. A failed request can reflect permissions or connectivity; investigate the recorded outcome before assuming an archive is absent.
Review subscriptions in PayPal
The operator configures PayPal credentials, webhook ID, approved plan IDs, site limits and accurate price labels in WordPress → BackupTool → PayPal billing. Checkout stays closed until this is configured. Sandbox and Live are separate environments.
Customers approve recurring terms on PayPal. A return from checkout grants no access by itself: the hub verifies the subscription ID, plan and account binding server-side. Signed webhooks and hosting cron refresh status. Existing evidence is kept when a subscription ends, while new site additions are disabled.
- 01Choose a configured planWorkspace / account
- 02Approve terms in PayPalPayPal checkout
- 03Verify subscription server-sideID, plan and account binding
- 04Apply verified accessSigned updates keep status current
Returning from PayPal does not grant access by itself. Sandbox subscriptions are test subscriptions; live billing requires the operator’s final configuration.
Keep keys and records private
Connector requests use HTTPS and HMAC-SHA256 signatures with replay protection. Site keys are encrypted using WordPress authentication salts. Changing those salts requires rotating and updating connector keys. Never place passwords or cloud API keys in recovery notes.
This release stores monitoring metadata rather than backup archives. Job events are kept for approximately 90 days. Recovery records remain until the connected site is removed. Manual cloud metadata checks support S3, B2 and Google Drive after configuration. PayPal requires operator configuration. Automatic restore testing and shared teams are not connected.
- 01Sign the request
The connector signs job metadata with the site key. HTTPS protects the connection.
- 02Check freshness
The hub checks the signature, timestamp and nonce to reject invalid or replayed requests.
- 03Keep the record private
The workspace limits records by owner. Credentials are encrypted with WordPress salts.
Start with your workflow.
Tell us which backup tools your agency uses.