How to View Logs and Events for Your Server and Site in xCloud

This guide shows xCloud users and support teams how to review and download server and site logs, locate a failed event, open the event-details modal, copy task output, and move to the most relevant log for troubleshooting. Use Events to understand what action ran and whether it succeeded. Use Logs to inspect the continuing server or site log stream related to the failure. For an overview of what it does and which plans include it, see the logs and events feature page.

Prerequisites

• Access to the xCloud team that owns the server or site.
• Permission to view the selected server or site.
• A server or site with at least one recorded event.
• A recent failure to investigate, if you want to follow the troubleshooting example.

Understand events, output, and logs

Events, task output, and raw logs answer different questions. Keep them separate while troubleshooting.

Surface	What it shows	Use it to answer
Events	An activity record with the event name, initiator, time, and status	What action ran, when did it run, and did it succeed?
Event output	The output captured for one event, opened through View	What did that specific task report?
Logs	A selected server or site log stream	What did WordPress or NGINX record before, during, or after the event?

To read the whole team’s history in one place, open All Events with View All Events in the events menu at the top of the dashboard. To read it from a script or an AI agent, see See Who Did What on Your Team with the xCloud Public API and MCP.

The Copy action in Event Details copies task output. The Download and Clear controls belong to the selected raw log; they do not act on event output. Download emails you a compressed copy of the log (see Download a log).

View server logs and events

1. Open the server. From the xCloud dashboard, select Servers, then select the server you want to inspect.

   Expected result: The server dashboard opens with its management navigation.

2. Open server logs. Select Logs in the server navigation.

   Expected result: xCloud displays the server log viewer. Select Nginx Access Log for request activity or Nginx Error Log for web-server errors. On OpenLiteSpeed servers, these labels read OpenLiteSpeed Access Log and OpenLiteSpeed Error Log instead; Plain servers show only Fail2ban Log and auth.log.

3. Open server events. Select Events in the server navigation.

   Expected result: The Events table lists recorded actions with their initiator, relative time, status, and a View action.

4. Open an event. Find the required row and select View.

   Expected result: The Event Details modal opens for that event. Failed output appears in the modal when the task recorded output.

View site logs

1. Open the site. From the xCloud dashboard, select Sites, then select the site you want to inspect.

   Expected result: The site dashboard opens.

2. Go to the log viewer. In the site navigation, open Site Monitoring, then select Logs.

   Expected result: The site log viewer opens with a log-type selector.

3. Choose a log type. Select one of the available site logs:

   • WordPress Debug Log: WordPress, plugin, or theme messages recorded by WordPress debugging.
   • Nginx Log: the combined NGINX log view available for the site.
   • Nginx Access Log: requests handled by NGINX.
   • Nginx Error Log: NGINX configuration and request-processing errors.

Expected result: xCloud loads the selected log. The toolbar shows the controls for that log, including Download and Clear when applicable. While the selected log is empty, Download stays greyed out.

Download a log

Download exports one server or site log and emails you a link to it, so you can keep more history than the viewer shows or attach the log to a support request.

• What you get: up to the most recent 10 MB of the selected log, compressed as a .gz file. Lines older than that 10 MB are not included.
• Where it goes: xCloud queues the export and emails the link to you, the person who requested it.
• How long it works: the link expires 24 hours after the export is ready. After that, request a new export.
• Which logs: any log you can select in the server or site log viewer, including the Docker Compose and Docker container logs of a Docker-based site.

Step 1: Open the log you want to export

For a server, go to ‘Servers’ → your server → ‘Logs’. For a site, go to ‘Sites’ → your site → ‘Site Monitoring’ → ‘Logs’. Choose the log in the log-type selector and wait for it to load.

Expected result: The log entries appear and the toolbar shows Download.

Step 2: Select Download

Select Download in the log toolbar.

Expected result: The Download Server Log modal (or Download Site Log for a site) opens and names the log it will export.

On a site, Download stays greyed out while the selected log is empty, because there is nothing to export. Choose another log, or reproduce the problem first so the log records it.

Step 3: Confirm the export

Check the log name in the modal, then select Download.

Expected result: The modal closes and a message confirms that the export is queued and the download link will arrive by email.

Step 4: Download the file from the email

Open the email from xCloud (Your Server Log Export Is Ready for a server log, Your Site Log Export Is Ready - Download Now for a site log) and select its download link within 24 hours. To read the file, open it with an archive tool or decompress it in a terminal:

gunzip -c server-error-log.gz | less

Expected result: You have the log as a text file on your computer.

If the export fails, xCloud emails you that the export failed instead of sending a link. On a server, this happens when the selected log is empty or no longer exists. Confirm in the viewer that the log has entries, then request the export again.

Download a server log with the API or MCP

Server logs can also be exported without the dashboard. Send POST /api/v1/servers/{uuid}/logs/download with the log type in the body. The token needs the write:servers scope and permission to manage that server’s logs and events.

curl -X POST 'https://app.xcloud.host/api/v1/servers/SERVER_UUID/logs/download' \
  --header "Authorization: Bearer $XCLOUD_TOKEN" \
  --header 'Content-Type: application/json' \
  --data '{"type": "error"}'

xCloud answers 202 with "status": "pending" and emails the link, the same as the dashboard. Valid type values are access, error, fail2ban and auth_log, plus the service logs of OpenClaw, Paperclip, Hermes and DeepSeek Harness servers (openclaw-gateway, openclaw-journal, paperclip-journal, hermes-dashboard, hermes-gateway, deepseek-harness-journal). A Plain server has no web server, so it has no access or error log.

AI agents connected to the xCloud MCP server run the same operation as the servers_logs_download tool (on the compact MCP profile, servers.logs.download through xcloud_execute_write). Site logs can be exported from the dashboard only.

Investigate a failed site event

1. Open site events. In the site navigation, open Site Monitoring, then select Events.

   Expected result: The Events table displays the event name, initiator, relative timestamp, status, and actions.

2. Locate a failed event. Look for the red Failed status and confirm that the event name matches the action you are investigating.

Expected result: You have identified the failed action without confusing it with a completed event. 3. Open the task output. Select View in the failed event’s row.

Expected result: Event Details opens for the selected event. The modal identifies the event and shows the number of output lines. 4. Read the failure from top to bottom. Review the final successful message, the failure message, and any suggested next step.

Expected result: You can identify where the task stopped and which troubleshooting surface to inspect next. 5. Copy the output when you need to share it. Select Copy in Event Details, then paste the text into your support conversation or internal incident note.

Expected result: The task output is available as text. Review it before sharing and remove any credential, token, IP address, email address, or customer identifier. 6. Open the relevant raw log. Close Event Details, open Logs, and choose the log that matches the failure. For a failed web-server configuration or reload event, begin with Nginx Error Log.

Expected result: You can correlate the event’s timestamp with the related raw log entries. 7. Correct the cause before repeating the action. Use the event output and raw log together to identify the failure, apply the appropriate correction, and then repeat the original dashboard action.

Expected result: A new event records the repeated action. Confirm that its status changes to Completed before considering the issue resolved.

Verification

You have completed the workflow when all of the following are true:

• The relevant event is visible in the server or site Events table.
• Selecting View opens the matching Event Details modal.
• The modal shows the task output or explicitly states No output available.
• For a failed web-server event, you can open Nginx Error Log and compare entries around the event time.
• After correcting and repeating the action, the new event shows Completed.

Troubleshooting

Symptom	Likely cause	Fix
Event Details shows No output available	The task did not record output, or output is not available for that event	Confirm the event name, time, and status, then use the related raw log for more detail.
View opens a different event than expected	The wrong table row was selected	Close the modal, match the event name and status again, then select View in that exact row.
A selected log keeps loading or remains empty	No entries are available yet, or the selected log does not match the failure	Refresh the view, reproduce the problem if safe, and choose the log that matches the component named in the event output.
Download or Clear is unavailable	The selected log has not loaded, is empty, or your access does not allow the action	Wait for the log to load, confirm that it contains entries, and verify your team permissions. Download is not shown in white-label client dashboards.
The download email does not arrive	The export is still running, or it failed	Wait a few minutes and check your spam folder. A failed export sends a “failed” email instead; confirm the log has entries and request it again.
The download link no longer works	The link expired 24 hours after the export was ready	Select Download again to request a new export.
The event failed but Nginx Error Log has no matching entry	The failure belongs to a different layer	Check the event output again. For WordPress or application-level failures, choose WordPress Debug Log or the other log named by the output.

Common mistakes

• Treating event output as a live log. Event output belongs to one task; raw logs continue to collect component activity.
• Opening the first failed row without checking its name and time. Several failures can occur close together, so confirm both before selecting View.
• Starting with Nginx Error Log for every problem. Choose the log that matches the failing component named in Event Details.
• Clearing a log before saving evidence. Download or copy the information you need before using Clear.
• Sharing copied output without reviewing it. Remove sensitive or customer-specific data before sending output outside your team.

Frequently asked questions

Why does Event Details say “No output available”?

That message means the selected event has no recorded task output available in the modal. The event row still provides the action, time, and status; use those details to inspect the relevant raw log.

Which log should I check after a failed NGINX reload?

Start with Nginx Error Log. Match entries around the failed event’s timestamp, correct the reported configuration or runtime problem, and then repeat the original action.

Can I download event output?

No. Event Details offers Copy for task output. Download belongs to the server and site log viewers, and it exports the selected log, not the output of one event.

How large is a downloaded log, and how long does the link work?

The export holds up to the most recent 10 MB of the selected log, compressed as a .gz file. The emailed link stays valid for 24 hours; after that, request a new export.

Next steps

• The unified Event Details modal shipped in xCloud v2.8.4, and log downloads in xCloud v2.9.2
• How to access the xCloud API to create the token for the log download endpoint
• How to troubleshoot NGINX configuration regeneration failures, the most common failed web-server event
• How to enable WP_DEBUG so the WordPress Debug Log has something to show

If an event fails and the output does not explain why, feel free to reach out to our support team with the copied output.