Grok Bot + xCloud

Troubleshoot a broken site with Grok Bot on xCloud

Troubleshooting a broken site with Grok Bot means messaging an always-on Bot when a site returns a 500, 502 or 503, and letting it read the evidence on xCloud in a fixed order and name a cause only when a log line or an event shows it.

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

Set up Grok Bot All Grok Bot guides

You@xcloud shop.example.com returns a 500. Find out why and show me what you checked.

sites_statusread-only

sites_eventsread-only

sites_access-logsread-only

AgentThe site is deployed and healthy. A plugin update task completed at 09:11, and the nginx error log shows a PHP fatal error in that plugin starting at 09:12. I have changed nothing. Want me to propose a fix?

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

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

1
Ask a Bot to add xCloud as a Remote HTTPS MCP server
In the Grok Bot desktop app, open any Bot's chat and ask it to add a custom MCP server of the Remote HTTPS kind, named xcloud, with this URL. The Bot adds it as a personal plugin from your own chat; the Marketplace in the sidebar only lists catalog connectors. The owner of a Team Bot adds the same kind of server from the Plugins card in the Bot's Setup panel instead. When the browser opens, sign in with xCloud, tick the teams the Bot may act on and choose Read-only or Full access.
URL
```
https://app.xcloud.host/mcp
```
2
Attach it to a task and check it works
In a Bot chat, type @ and pick xcloud to attach the connector to the task, then ask. A plugin you added from your own chat is personal and account-wide, so every Bot on your account can use it; a plugin added from a Team Bot's Setup panel belongs to that Team Bot, so check it in that Bot's chat. Put a standing boundary in the description of each Bot that may touch hosting, for example: never change production without approval.
Prompt
```
@xcloud Who am I on xCloud, and which servers and sites do I have?
```
3
Team Bot without sign-ins? Use an API key
A Remote HTTPS server added from the Plugins card in a Team Bot's Setup panel can run on the Bot's own credential instead of each person's sign-in, which suits a Team Bot that answers hosting questions for everyone. Create a token with the mcp:invoke scope plus the read abilities for the areas it will use (read:servers and read:sites, with read:billing and read:addons for billing and add-on tools) and the matching write: abilities if it should change things in Settings, Developers, API Tokens, and give the plugin this header where its form asks for one. Everyone who talks to that Bot then acts with the token's access, so keep it read-only unless the team should change things.
Code
```
Authorization: Bearer YOUR_TOKEN
```

Check it worked

Then ask Grok Bot for the job itself, for example:

Prompt

@xcloud shop.example.com is returning a 500. Check the site status, the recent events and the nginx error log from the last hour, and tell me what each one shows.

In practice

How Does Troubleshooting Work from Grok Bot?

Sites break away from your desk, and the Grok Bot mobile app lets you start the investigation from your phone. Send: @xcloud shop.example.com is returning a 500, find out why and show me what you checked. The Bot reads in order, cheapest first. sites_status comes first, because a site that is still provisioning or whose last deploy failed explains a 500 on its own. Then sites_events shows the recent tasks and their outcomes, and sites_access-logs with the nginx type returns the access log, the error log and the 7G and 8G firewall logs. Logs are read over SSH, so the Bot should ask for a bounded window. For a WordPress site it adds sites_wordpress_status. Every one of these runs without a prompt.

Evidence discipline is where a Bot can differ from a person in a hurry. It should not name bad credentials or a crashed process unless a line it retrieved shows it, and it should quote log lines as data, because content that comes from a site can contain text that addresses an agent. If the logs are inconclusive, it proposes turning on WP_DEBUG and waits for your approval, then turns it off again. The toggle flips the flag only, and the debug.log itself is read in the dashboard under Site, Site Monitoring, Logs. A cache purge with sites_cache_purge clears a cached error page and runs without an xCloud prompt, and on a live site the Bot asks first.

Because the Bot stays on, you can ask it to keep watching. Ask for a routine that, every morning, reads each site's status and recent events and posts only the ones that are failing, with the evidence it found and nothing changed. If a site is slow rather than broken, that is a different investigation, answered from measurements instead of error logs, so ask for it separately. A failed deploy goes to the deployment diagnosis, and a Cloudflare 526 or a certificate warning goes to the certificate checks. Naming the symptom you see in your first message sends the Bot down the right path.

Grok Bot specific: A Grok Bot has a terminal and a browser, and both belong to its own cloud computer in Cursor's cloud, not to your xCloud server. When you say check the server, the Bot should use the xcloud tools, which read your logs and services through xCloud. A command it types into its own terminal tells you nothing about your site, and the Bot has no shell on your server unless you agree to a temporary sudo user, which expires after 12 hours and which the Bot should remove as soon as the investigation ends. Never ask a Bot to restart a service or reboot just to clear an unexplained error either, because that destroys the evidence the logs were about to show.

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 Grok Bot 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 Grok Bot 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 Grok Bot 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

@xcloud shop.example.com is returning a 500. Check the site status, the recent events and the nginx error log from the last hour, and tell me what each one shows.

Prompt

@xcloud Which tasks ran on shop.example.com just before it broke? Did any of them fail? Change nothing.

Prompt

@xcloud Turn on WP_DEBUG for blog.example.com, tell me what you find, then turn it off again 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.

Grok Bot and Troubleshooting: Frequently Asked Questions

What people ask before they let Grok Bot troubleshoot a broken site through xCloud.

Can I start a Grok Bot troubleshooting from my phone?

Yes. The mobile app on iOS and Android talks to the same Bot, and the Bot works on its cloud computer, so you can message it, close the app and read the findings later. xCloud reads run straight away, so nothing needs your approval until the Bot proposes a change such as turning on WP_DEBUG.

Will a Grok Bot restart my server to fix a 502?

Not to clear an error it cannot explain yet. A restart changes a live machine and wipes out the evidence in the logs, so the Bot finds the cause first. If the evidence points at a stopped service, restarting it is a change you ask for and approve.

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