Book a demo
Book a demo
Login

Operations WordPress

Plan WordPress server capacity review

Inspect resource patterns and traffic expectations before a scale decision. 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 slows during monthly registration peaks. The owner needs to review server capacity using a time series and a business transaction, not a single green snapshot.

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

Name peak workload

Where
Business calendar and site analytics
Permissions
Authorized xCloud read access to the named team and site; the relevant app or provider owner supplies records outside xCloud.
Inputs
Registration peak times, affected URL, expected latency
Action
Identify the user action that slows and the hours it happens. Record concurrent users and recent deployments or campaigns.
Expected result
A measurable performance question.
Verify
Reproduce a non-sensitive registration or form in a peak-like test.
If it fails
If only one user's network is slow, inspect client path before server sizing.

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

Step 2 of 5

Collect resource trends

Where
xCloud server/site monitoring
Permissions
Authorized xCloud read access to the named team and site; the relevant app or provider owner supplies records outside xCloud.
Inputs
CPU, RAM, disk, PHP workers, traffic history
Action
Read a period covering quiet and peak hours. Note missing samples and correlate resource spikes with slow requests.
Expected result
A time-aligned capacity baseline.
Verify
Compare metrics to reported timestamps.
If it fails
If monitoring is unavailable, mark the gap and collect logs before deciding.

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

Step 3 of 5

Find the limiting layer

Where
PHP slow logs, database and app checks
Permissions
Authorized WordPress/WooCommerce application administrator or delegated role with rights for this task; hosting access alone is insufficient.
Inputs
Error log, slow requests, plugin changes
Action
Inspect whether queueing, PHP workers, database calls, storage or external API latency explains the task. Check cache behavior of dynamic pages.
Expected result
A plausible cause with evidence.
Verify
Compare a slow request against resource and application logs.
If it fails
If resource headroom exists, investigate code/query or provider delays instead of resizing.

Sources: Create WordPress pages · xCloud site PHP settings

Step 4 of 5

Compare options and cost

Where
xCloud server plan and change ticket
Permissions
Authorized xCloud read access to the named team and site; the relevant app or provider owner supplies records outside xCloud.
Inputs
Resize option, PHP tuning, cache exclusion
Action
Estimate capacity and cost of an approved server change against narrower PHP or plugin repairs. Note restart or maintenance impact.
Expected result
A decision with tradeoffs and owner.
Verify
Have the owner confirm which option addresses the observed bottleneck.
If it fails
If evidence is insufficient, pilot one reversible change rather than broad tuning.

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

Step 5 of 5

Verify after change

Where
External browser and xCloud monitoring
Permissions
Authorized WordPress/WooCommerce application administrator or delegated role with rights for this task; hosting access alone is insufficient.
Inputs
Same task, before/after time series
Action
After separately approved action, repeat the registration flow and compare latency, errors and resource headroom at comparable load.
Expected result
An observed improvement or rollback decision.
Verify
Check performance and correctness of the business task.
If it fails
If latency remains, revert ineffective tuning and continue diagnosis.

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