ChatGPT dots + xCloud

Troubleshoot a broken site with ChatGPT dots on xCloud

Troubleshooting a broken site with a ChatGPT dot means handing your always-on OpenAI agent an error report, such as a 500 on shop.example.com, and letting it read xCloud's status, events and logs and come back with a cause it can point to.

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

Set up ChatGPT dots All ChatGPT dots guides

Youshop.example.com is returning a 500. Find out why and show me what you checked.

sites_statusread-only

sites_eventsread-only

AgentThe site status is normal, but a plugin update failed at 07:41 and the errors began right after. I am reading the nginx error log for the last hour to confirm.

sites_access-logsread-only

AgentThe error log shows a PHP fatal from that plugin starting at 07:42. I changed nothing. Do you want me to look at how to roll the plugin back?

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 ChatGPT dots to Troubleshoot a broken site on xCloud?

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

1
Create the xCloud MCP plugin in ChatGPT
Plugins are shared across your dot, ChatGPT, ChatGPT Work and Codex, so you set xCloud up once. In ChatGPT on the web, turn on Developer mode under Settings, Security and login, open the Plugins page, select the plus button and create an app named xcloud with this MCP server URL and OAuth as the authentication. Sign in with xCloud, tick the teams and choose Read-only or Full access. Then open your personal Plugins page, open xcloud and select the plus button to install it; until it is installed, your dot cannot see it. If ChatGPT already has the xcloud plugin installed, skip this step. That path is for a personal account. In a Business, Enterprise or Edu workspace the controls sit under Apps instead. On Business only an admin or owner can use Developer mode: they turn it on while creating the app from Workspace settings, Apps, Create, and publish it from Workspace settings, Apps. On Enterprise and Edu an admin or owner can also toggle Developer mode under Settings, Apps, Advanced settings, and a member granted developer access under Permissions and Roles turns it on there too and can create and test the app from their own Settings, Apps, Create, but only an admin or owner can publish it. An ordinary member cannot do this, so ask an admin to publish the xcloud app; then open Settings, Plugins, select xcloud, install it if offered and choose Connect, sign in to xCloud and pick the teams and access level, and only then start at the next step.
URL
```
https://app.xcloud.host/mcp
```
2
Check the plugin is connected for your dot
Open your dot's profile, then Customize and Plugins, and make sure xcloud is connected. The screen uses the shared ChatGPT plugin settings, so a plugin connected in ChatGPT appears here too. Then give your dot a first task that names xCloud.
Prompt
```
Using xcloud, who am I on xCloud, and which servers and sites do I have?
```
3
Add a custom rule for hosting changes
Under Customize, Custom rules, describe the action and choose Ask before taking action. Pre-approved means you asked for the action in your prompt. xCloud stops for confirmation on its own before it creates, deploys, updates, reboots or deletes anything, but a rule keeps the approval visible in your conversation and stops a scheduled task from proposing changes you did not ask for.
Prompt
```
Ask before taking action: anything that creates, deploys, updates, reboots or deletes a server or site on xCloud.
```

Check it worked

Then ask ChatGPT dots for the job itself, for example:

Prompt

shop.example.com is returning a 500 error. Check the site status and the recent events first, then the nginx error log for the last hour, and tell me what you found and what you ruled out. Change nothing.

In practice

How Does Troubleshooting Work from ChatGPT dots?

Investigation takes several reads, and a dot can keep going while you do something else. Tell it the symptom in the ChatGPT desktop app, the mobile app or Slack, for example shop.example.com is returning a 500, find out why and show me what you checked. It follows a fixed read order. sites_status comes first, because a site still deploying or in a failed state explains a 500 on its own. Then sites_events shows the tasks that ran just before the break, sites_access-logs with the nginx type and a limit returns the error log, and sites_wordpress_status covers WordPress health. Every one of those is a read, so it runs without approval, and the dot quotes log lines as data and never follows them as instructions.

What a dot adds is memory and a clock. Because it shares memory with ChatGPT, it can recall that the shop broke last Tuesday after a plugin update. You can also give it a standing watch: on weekday mornings, check the status of shop.example.com and, if it is not normal, read the recent events and the error log and message me what you found, changing nothing. You then start the day with evidence already gathered. What the dot must not do is restart a service or reboot to clear an unexplained error. A restart is a real change and it destroys the evidence, and xCloud lets servers_services_restart run without a prompt, so put a Custom rule of Ask before taking action on it.

A few steps need your explicit yes naming the site: turning WP_DEBUG on with sites_wp-debug and off again afterwards, creating temporary shell access through a sudo user that expires after 12 hours, and a rescue action. The debug.log, Laravel, PM2 and Docker Compose logs are dashboard-only, under Site, Site Monitoring, Logs. So if the readable logs show nothing, your dot says what it ruled out and gives you that path instead of naming a cause the evidence does not support.

ChatGPT dots specific: A dot's habit of acting on a schedule is the risk in this job, so keep a scheduled watch to reading and reporting. A cache purge or a service restart is a routine action that xCloud runs without a prompt, which makes your Custom rules the only gate. OpenAI's help center says full MCP support with write actions is in beta on Business, Enterprise and Edu workspaces, and Pro accounts connect MCP apps with read and fetch permissions only, so on Pro the investigation, which is all reads, works in full and any fix is yours to make.

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 ChatGPT dots 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 ChatGPT dots 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 ChatGPT dots 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

shop.example.com is returning a 500 error. Check the site status and the recent events first, then the nginx error log for the last hour, and tell me what you found and what you ruled out. Change nothing.

Prompt

Every weekday at 7:30, check the status of shop.example.com. If it is not normal, read the recent events and the error log and message me the evidence. Do not restart or purge anything.

Prompt

Check WordPress health on the blog site. If the logs do not explain the error, tell me what you would turn on, wait for my yes before you switch WP_DEBUG on, and switch it off when I say I am done.

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.

ChatGPT dots and Troubleshooting: Frequently Asked Questions

What people ask before they let ChatGPT dots troubleshoot a broken site through xCloud.

Can my ChatGPT dot find out why my site returns a 500?

Yes, when xCloud holds the evidence. It reads the site status, the recent events, the nginx error log and WordPress health, then tells you what it found and what it ruled out. If those reads show nothing, it gives you the dashboard log path instead of guessing a cause.

Will my dot restart services to fix an error by itself?

It should not. A restart changes a live machine and erases the evidence, so ask the dot to report first. xCloud runs a service restart without its own prompt, so add a Custom rule of Ask before taking action for restarts and reboots.

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