Book a demo
Book a demo
Login

Operations WordPress

Check WordPress backup completion routinely

Review backup status and confirm the team knows how to investigate a missed run. Check the named site's prerequisites, task result, backup scope and recovery handoff with xCloud.

Technical review: · Source reviewed; no production deployment test claimed

Published · Updated · xCloud editorial

Read this guide as Markdown

Requirements and responsibilities

Illustrative situation

An agency has a daily WordPress backup schedule but one client site silently missed two runs. A named operator needs a routine completion check and escalation path.

Choose the approach

Dashboard and application procedure

Follow these steps yourself, or use the scoped AI handoff below for supported hosting operations.

Step 1 of 5

Define expected cadence

Where
Client recovery policy
Permissions
Authorized xCloud read access to the named team and site; the relevant app or provider owner supplies records outside xCloud.
Inputs
Site ID, scheduled time, maximum age
Action
Write the expected latest completion time and the owner who checks it. Include files/database and remote destination requirements.
Expected result
An objective overdue threshold.
Verify
Compare policy with current dashboard settings.
If it fails
If the policy is unwritten, agree it before calling a backup late.

Sources: xCloud MCP documentation and connection profiles · xCloud agent capability boundaries

Step 2 of 5

Inspect latest runs

Where
xCloud Site Backup → Previous Backups
Permissions
Authorized xCloud site owner with dashboard rights for the exact setting, backup, staging or restore action and a reviewed target.
Inputs
Completed, Running and Failed rows
Action
Review recent rows by time and status. Confirm the newest Completed snapshot includes the required files and database scope.
Expected result
A pass/fail for the current interval.
Verify
Compare snapshot time to current time and expected cadence.
If it fails
If a job is still running beyond normal time, investigate its task status.

Sources: Site backups in xCloud · xCloud agent capability boundaries

Step 3 of 5

Check destination health

Where
xCloud backup provider and server storage
Permissions
Authorized xCloud site owner with dashboard rights for the exact setting, backup, staging or restore action and a reviewed target.
Inputs
Provider authorization, capacity, error text
Action
Inspect failed-job detail, remote provider connection and local disk capacity. Separate source-site error from destination error.
Expected result
A plausible failure cause and owner.
Verify
Test provider access through supported dashboard checks.
If it fails
If credentials expired, rotate through the owner rather than embedding them in logs or prompts.

Sources: Site backups in xCloud · xCloud agent capability boundaries

Step 4 of 5

Create a corrective point

Where
xCloud Backup Now
Permissions
Authorized xCloud site owner with dashboard rights for the exact setting, backup, staging or restore action and a reviewed target.
Inputs
Approved site, storage correction, maintenance window
Action
After fixing the cause, start an on-demand backup and wait for terminal completion. Do not treat request accepted as recovery.
Expected result
A fresh completed recovery point.
Verify
Inspect new row scope, destination and timestamp.
If it fails
If it fails again, escalate with task ID and refrain from risky site changes.

Sources: Site backups in xCloud · xCloud agent capability boundaries

Step 5 of 5

Log and schedule next check

Where
Agency ticket/calendar
Permissions
Authorized xCloud site owner with dashboard rights for the exact setting, backup, staging or restore action and a reviewed target.
Inputs
Failure period, last good snapshot, next reviewer
Action
Record missed interval, potential data-loss exposure, resolution and next manual or scheduled inspection.
Expected result
A closed incident with continuing ownership.
Verify
Have next reviewer locate the new completed row.
If it fails
If no reviewer is assigned, leave the gap open.

Sources: WordPress website maintenance reports for clients · xCloud agent capability boundaries

Maintenance

Recovery decisions

AI handoff

Connect an authorized xCloud MCP profile and discover its exact tools and team scope. The packaged REST wrapper is GET-only; use dashboard or app controls for undocumented writes.

Supported scope

  • Confirm requirements and inspect resources mcp · read

    Discover the connected profile and operation schema first; only teams granted to the connection are visible.

    Checkpoint: Confirm exact team, server and site identity. Use dashboard_url returned by the resource; do not invent a dashboard link.

    Operation identifiers and scopes to discover

    teams.index, servers.show, sites.show

    Scopes: read:servers, read:sites

    xCloud MCP documentation and connection profiles · xCloud agent capability boundaries

Copyable agent brief

Manual checkpoints

  • Approve exact site, target, cost and any write or maintenance window after inspecting the proposed plan.
  • An authorized WordPress administrator must configure and test app users, content, integrations and business rules in the app.
  • Native WordPress staging, backup schedule/settings, push/pull and all restores are dashboard-only; Docker restore is dashboard-only and replaces state.
  • Reconcile data created after the chosen recovery point before any destructive restore.
Feature coverage

Sources

Continue

Explore all use cases