Book a demo
Book a demo
Login

Operations WordPress

Respond to a WordPress site outage

Check reachability, recent changes, server health, and recovery options in a documented order. 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

A WordPress site becomes unreachable during business hours. The responder needs to distinguish DNS, certificate, server and application failures before choosing repair or restore.

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

Confirm outage footprint

Where
External browser and DNS resolver
Permissions
Authorized xCloud read access to the named team and site; the relevant app or provider owner supplies records outside xCloud.
Inputs
Canonical URL, error time, alternate network
Action
Check whether DNS resolves, TLS connects and both public and admin routes fail. Ask one independent observer to reproduce.
Expected result
A precise symptom and start time.
Verify
Compare apex/www answers and HTTP status from outside the server.
If it fails
If only one client network fails, investigate local DNS before server changes.

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

Step 2 of 5

Inspect host and site state

Where
xCloud server/site status and logs
Permissions
Authorized xCloud read access to the named team and site; the relevant app or provider owner supplies records outside xCloud.
Inputs
Team, server, site IDs, recent events
Action
Read resource state, disk, service health, deployment history and error logs around the incident.
Expected result
A likely failure layer.
Verify
Compare log timestamps to outage start.
If it fails
If host metrics are unavailable, mark them unknown instead of healthy.

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

Step 3 of 5

Isolate recent change

Where
WordPress update history and app logs
Permissions
Authorized WordPress/WooCommerce application administrator or delegated role with rights for this task; hosting access alone is insufficient.
Inputs
Plugin/theme/core changes, PHP setting
Action
Compare failures with recent updates or configuration changes. Reproduce safely on staging where possible.
Expected result
A narrow repair candidate.
Verify
Check whether admin login or static assets still work.
If it fails
If evidence points to DNS or TLS, do not restore WordPress data.

Sources: Manage WordPress plugins · Create a staging environment in xCloud

Step 4 of 5

Apply approved recovery

Where
Relevant xCloud or WordPress control
Permissions
Authorized xCloud site owner with dashboard rights for the exact setting, backup, staging or restore action and a reviewed target.
Inputs
Selected fix, backup, data gap
Action
Fix the diagnosed routing/service issue or roll back a narrow component after approval. Use dashboard restore only for verified data damage and preserve newer records.
Expected result
Service response returns without avoidable data loss.
Verify
Wait for terminal operation and inspect public/admin routes.
If it fails
If the first repair fails, stop repeated writes and escalate with logs.

Sources: Manage WordPress core, themes and plugins · xCloud agent capability boundaries

Step 5 of 5

Validate business return

Where
Public site, app and external provider
Permissions
Authorized WordPress/WooCommerce application administrator or delegated role with rights for this task; hosting access alone is insufficient.
Inputs
Test login, form or checkout, alert owner
Action
Run a representative customer task and check provider result. Record incident timeline, affected data and follow-up prevention.
Expected result
A confirmed recovery, not just an HTTP 200.
Verify
Compare task output with pre-incident expectations.
If it fails
If business flow still fails, keep incident open and customer communication active.

Sources: Manage WordPress plugins

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