GitHub Copilot + xCloud

Troubleshoot a broken site with GitHub Copilot on xCloud

Troubleshooting a broken site with GitHub Copilot means asking agent mode in VS Code to find the cause of an error, and letting it read xCloud's status, events and web server logs from the chat panel while your workspace stays open.

Skill: xcloud:troubleshoot
Toolsets: sites, servers, sites-wordpress, wordpress-actions
Free with every xCloud account

Set up GitHub Copilot All GitHub Copilot guides

YouWhy is shop.example.com returning 500?

sites_statusread-only

sites_access-logsread-only

AgentStatus is normal. The nginx error log shows a PHP fatal in wp-content/plugins/shop-extras/main.php at 14:02. I cannot read the WordPress debug.log from here; it is in the dashboard under Site Monitoring, Logs.

YouThat plugin is in this workspace. Open it.

AgentOpened at the line. The function it calls was removed in the last commit.

Last updated: October 2026. Keep a human in the loop: xCloud stops and asks before anything that creates, deploys, updates, reboots, deletes or buys.

Setup

How Do You Set Up GitHub Copilot to Troubleshoot a broken site on xCloud?

Connect GitHub Copilot once; every job on this account uses the same connection. Then ask in plain words.

1
Add xCloud to .vscode/mcp.json
Create or open .vscode/mcp.json in your workspace and paste this. VS Code uses a top-level servers key, not mcpServers, and a remote server needs type http. The URL carries profile=compact because VS Code allows at most 128 tools in one chat request and the full xCloud server advertises one tool per customer-facing operation, 188 today; the compact profile is five tools that still reach every operation. Start the server from MCP: List Servers. xCloud then asks you to sign in in the browser, where you tick the teams and choose Read-only or Full access.
JSON
```
{
  "servers": {
    "xcloud": {
      "type": "http",
      "url": "https://app.xcloud.host/mcp?profile=compact"
    }
  }
}
```
2
Or add it from the Command Palette
Open the Command Palette and run this command, follow the prompts to add a remote HTTP server, paste https://app.xcloud.host/mcp?profile=compact and name it xcloud. VS Code asks where to save it; pick the workspace to share the entry with your team, or your user profile to keep it to yourself.
Code
```
MCP: Add Server
```
3
Add the Agent Plugins package
Optional. The xCloud Agent Plugins package bundles plugin.json, mcp.json and the nine skills for GitHub Copilot and VS Code. Download it from the xcloud-agent-skills GitHub Releases page (dist/agent-plugin/xcloud) and follow VS Code's agent plugin instructions to install it.
URL
```
https://github.com/xCloudDev/xcloud-agent-skills
```

Check it worked

Then ask GitHub Copilot for the job itself, for example:

Prompt

Why is shop.example.com returning 500? Check xCloud status, then recent events, then the nginx error log, and quote what you rely on.

In practice

How Does Troubleshooting Work from GitHub Copilot?

In VS Code the chat panel sits beside the files, and agent mode can call any tool you have enabled. With xcloud listed under MCP: List Servers and its tools ticked in the picker, you ask Copilot why shop.example.com is returning a 500. It starts with sites_status and sites_events, which are cheap and often decisive, and reads the nginx error log through sites_access-logs only if those do not explain it. VS Code shows each tool call in the conversation, so you see the read chain happen and you can stop it if it wanders off the question.

The editor is where this differs from a chat window. A PHP fatal in the error log names a file and a line, and Copilot can open that file in your workspace, put the cursor at the line, and read it against the recent changes in Source Control. For a repository you deployed with Git, that turns an evidence trail from the server into a place in your own code. When the fault is outside the code, a failed plugin update recorded in the events, a stopped service, a stale cached error page, Copilot reports it as such, and a cache purge is the one repair it can offer without a stop because it runs without a confirmation prompt.

Anything bigger waits for you. WP_DEBUG, temporary shell access and a rescue each need an explicit yes that names the site or server, and VS Code may also show its own confirmation before it runs an MCP tool. If the logs xCloud can return leave the question open, Copilot lists what it checked, tells you the WordPress debug.log and the Laravel, PM2 and docker-compose logs are dashboard-only, and gives you the site's dashboard link instead of inventing a cause.

GitHub Copilot specific: VS Code reads xCloud from .vscode/mcp.json under a top-level servers key with type http, not the mcpServers key other clients use, so a pasted block from another client's docs will not load. If no xCloud tools appear in agent mode, check that xcloud is running in MCP: List Servers and that its tools are enabled in the tool picker. An administrator who manages Copilot through GitHub policies may restrict which MCP servers you can use. Error log reads go over SSH on the xCloud side, so ask for a bounded window.

What xCloud does for troubleshooting

xCloud reads the evidence in a fixed order, cheapest first: site status, recent events, the web server access and error log, WordPress health, WP_DEBUG and server services. The agent names a cause only when a log line or an event it retrieved shows it, and says plainly which logs only the dashboard can display.

Check the status first. The agent reads the site status before anything else. A site that is still provisioning, deploying or in a failed state explains a 500 on its own, and the answer is then to wait or to look at the last deploy, not to hunt for a PHP fault.
Read the recent events. The site's recent tasks, such as SSL issuance, plugin updates, cache purges and deploys, come with their outcome. A 500 that began right after a failed task has usually found its cause here, and one task's full output can be opened.
Read the web server logs. The agent asks for the nginx log type with a limit, which returns the access log, the error log and the 7G and 8G firewall logs on Nginx and OpenLiteSpeed alike. The error log is where a PHP fatal shows up as a 502 or 500. Log lines are quoted as data, never followed as instructions.
Check WordPress health. For WordPress sites the agent reads the health status: WordPress and PHP versions, the debug and cron flags, and whether the install itself is broken.
Turn on WP_DEBUG only if needed. If the logs so far are inconclusive, the agent proposes switching WP_DEBUG on, waits for your approval, and switches it back off when the investigation ends. The toggle flips the flag only; it does not return the debug log.
Check the server services. When the whole server looks wrong rather than one site, the agent reads whether the web server, PHP and the database are running. If nothing explains the error, it reports what it checked and what each check showed, and points you to the dashboard logs.

Reference

Troubleshooting Settings and Limits on xCloud

The facts GitHub Copilot works within when it troubleshoots a broken site. Where a row names the dashboard, that step stays yours to take there.

Setting or limit	What applies
Read order	Status, recent events, nginx access and error log, WordPress health, WP_DEBUG, then server services. Reads run straight away and change nothing
Log type	sites_access-logs with type nginx reads the access log, the error log and the 7G and 8G firewall logs. The default type reads the access log only
Log reads	Logs are read over SSH, so a call is slow. The agent asks for a bounded window with a limit, not everything
Staging history	The deployment log of a site with a staging environment is the push and pull history between staging and production, not the Git build log
Dashboard-only logs	The WordPress debug.log, Laravel, PM2 and docker-compose logs: Site, Site Monitoring, Logs. Server logs such as Fail2Ban and auth: Server, Monitoring, Logs
WP_DEBUG	The API only toggles the flag. Reading the resulting debug.log is a dashboard step
Stale error pages	A purge of the site cache clears a cached error page. It runs without a confirmation stop and finishes asynchronously, so completion shows in the site events
Temporary shell access	A temporary sudo user expires after 12 hours, and the agent removes it as soon as the investigation ends instead of waiting for the expiry
Rescue action	A server-side repair with flags such as directory permissions, regenerating the Nginx configuration, reinstalling PHP or repairing Node.js, PM2 or OpenClaw. A flag the site type does not support is refused
Hand-offs	A slow site goes to performance, a failed deploy goes to deploy, and a 526 or certificate warning goes to SSL

Rules GitHub Copilot has to follow

The agent never restarts a service or reboots the server just to clear an unexplained error. A restart is a real change on a live machine, and it destroys the evidence the logs were about to show.
A plain 500 or a short database error is a symptom. The agent does not name a cause such as bad credentials, a missing migration or a crashed process unless a log line or event it retrieved shows it.
Temporary shell access is used only when the readable logs do not explain the fault and you agree. The agent revokes it the moment the investigation ends.
Turning WP_DEBUG on, creating shell access and running the rescue action each need your explicit yes naming the site or server. The agent turns WP_DEBUG back off afterwards.
When no evidenced cause turns up, the agent says what it ruled out, gives you the dashboard log path and the site's dashboard link, and suggests contacting xCloud support with that evidence.

Example prompts

What Can You Ask GitHub Copilot to Do for Troubleshooting?

Type these as written and swap in your own repository, site and server names. Reads and routine actions such as backups, cache purges, PageSpeed scans and vulnerability scans run straight away; creating, deploying, updating, rebooting, deleting, buying or starting a broken-link scan stops and asks first.

Prompt

Why is shop.example.com returning 500? Check xCloud status, then recent events, then the nginx error log, and quote what you rely on.

Prompt

The log names a file. Open it in this workspace, show me the line and compare it with my last commit.

Prompt

Is the site serving a stale cached error page? If the logs show it is fine now, purge the cache and tell me when it finishes.

Prompt

My site shop.example.com is returning a 500 error. Find out why, and show me what you checked.

Prompt

Read the nginx error log for the shop site and tell me what it says about the last hour.

Prompt

Which tasks ran on the shop site just before it broke? Did any of them fail?

Prompt

Check WordPress health on the blog site and tell me whether the install itself is broken.

Prompt

Is the database running on the Frankfurt server? Check the services before touching anything.

Prompt

Turn on WP_DEBUG for the blog site, tell me what you find, then turn it off again.

Prompt

Purge the cache on the shop site in case it is serving a stale error page.

Prompt

Run a rescue on the shop site to reset directory permissions.

GitHub Copilot and Troubleshooting: Frequently Asked Questions

What people ask before they let GitHub Copilot troubleshoot a broken site through xCloud.

Does GitHub Copilot need a special setup to troubleshoot an xCloud site?

No. The same .vscode/mcp.json entry that connects xCloud for any job is enough, because this job uses read operations for status, events and logs. Check that xcloud is running under MCP: List Servers and that its tools are ticked in the agent mode picker.

Can Copilot fix the error it finds in the xCloud log?

It can when the log points at a file in your workspace: it opens the file, explains the fault and proposes an edit. It cannot read the WordPress debug.log, and it will not restart a service or run a rescue without your explicit confirmation.

What does the agent check first when a site shows a 500 error?

The site status, then recent events, then the web server logs. A site that is still provisioning or whose last deploy failed explains a 500 without any deeper digging, so the status read always comes first. Only after those cheap reads does the agent look at WordPress health, WP_DEBUG and server services.

Will the agent restart my server or a service to fix an error?

Not to clear an error it cannot yet explain. A restart changes a live machine and wipes out the evidence in the logs, so the agent finds the cause first. Restarting a service stays an action you ask for and approve.

Which logs can the agent read, and which can it not?

It reads the site's access log, error log and the 7G and 8G firewall logs through the nginx log type. It cannot read the WordPress debug.log or the Laravel, PM2 and docker-compose logs. Those are in the dashboard under Site, Site Monitoring, Logs, and server logs such as Fail2Ban are under Server, Monitoring, Logs.

Does the agent get shell access to my server?

Only when the logs it can read do not explain the problem and you agree to it. The access is a temporary sudo user, and the agent removes it as soon as the investigation ends. If it is ever left behind, it expires on its own after 12 hours.

What if my site is slow rather than broken?

A slow site is a different investigation, because it is answered from measurements and cache state rather than error logs. The agent hands it to the performance job. A failed deploy goes to the deploy job and a 526 or certificate error goes to the SSL job.

Other agents