# How Auto Healing Works in xCloud

> How xCloud Auto Healing detects failed server services and restarts them automatically — coverage by stack, the retry limit, checking status, and its limits.

xCloud Auto Healing monitors eligible services required by a managed server and attempts to restore them after monitoring reports an unexpected failure. It can reduce downtime caused by a stopped service, but it does not replace server monitoring or resolve the underlying cause of every failure.

## What Auto Healing does

For an eligible service managed by xCloud, Auto Healing can:

-   track the service state reported by server monitoring;
-   detect when the service is no longer active;
-   attempt to start or restart the service automatically;
-   record recovery success or failure in the related server task; and
-   update the service status shown in xCloud.

Auto Healing does not send a separate customer notification for every recovery event. Check the service status and related server tasks when you investigate a failure.

The **Server Utilities** table shows installed services and their current status. A service appearing as **Active** does not confirm that Auto Healing is enabled for that service or that an automatic recovery occurred.

## Auto Healing coverage by server stack

**Coverage is stack-specific.** xCloud only attempts automatic recovery for services that the current server stack marks as eligible and required.

| Server stack or service context | Current Auto Healing coverage |
| --- | --- |
| Standard NGINX or OpenLiteSpeed server | The managed database service, Supervisor, and Redis when Redis is configured. |
| PHP on a standard server | PHP recovery uses separate required-version checks rather than the standard service list. |
| Docker with NGINX | Docker and Supervisor. NGINX is not included in this stack's Auto Healing list. |
| Agentic stacks | NGINX and the stack-specific agent service. Paperclip also includes PostgreSQL. |
| OpenLiteSpeed and OpenSSH | The OpenLiteSpeed web server service and OpenSSH can appear in **Server Utilities**, but they are not currently Auto Healing-eligible. |

The exact set can change when the server stack, database, cache, or managed components change. Do not assume that every service displayed in **Server Utilities** is covered.

## Prerequisites

Before using this guide, make sure that:

-   the server is connected to and managed by xCloud; and
-   your xCloud account can access the server's **Management** area.

## View service status

1.  Sign in to the xCloud dashboard and open the server.
2.  Go to **Management** → **Settings**.
3.  Find the **Server Utilities** section.

**Expected result:** The table lists the server's installed services and shows the current status of each one. An **Active** status means the service is currently running. It does not prove that Auto Healing is enabled or that Auto Healing restarted the service.

## Understand the available controls

The controls in **Server Utilities** are manual service-management actions. They are separate from the automatic recovery process.

| Option | What it does |
| --- | --- |
| **Status** | Shows the current state reported for the service. |
| **Reboot** | Manually restarts the selected service. |
| **Disable** | Stops the selected service at that time. This is not a persistent opt-out from Auto Healing. If the service is eligible and required, a later monitoring cycle can start it again. |
| **Install a Service** | Adds a supported service to the server. Available options depend on the server configuration. |

Do not disable or restart services on a production server simply to test Auto Healing. These actions can interrupt websites and applications using the service.

## What happens after a failure

When monitoring reports that an eligible required service is not active, xCloud attempts to recover it. A successful recovery marks the service **Active**, resets its recorded Auto Healing failure count, and keeps automatic recovery enabled.

If an automatic recovery attempt fails, xCloud marks the service **Failed** and records the failed attempt. xCloud permits up to two failed recovery attempts. After the second failed attempt, automatic healing for that service is switched off to prevent an endless restart loop.

Automatic healing remains off until monitoring reports the service as active again. When the service becomes active, xCloud resets the failure count and enables automatic healing again.

## Verify recovery status

1.  Return to **Management** → **Settings** → **Server Utilities**.
2.  Check whether the affected service reports **Active** or **Failed**.
3.  Review the related server task for the recovery result.

**Expected result:** A recovered service reports **Active**. A service that could not be recovered reports **Failed**, and its related task contains the recovery result.

## Troubleshoot repeated failures

| Symptom | Likely cause | What to do |
| --- | --- | --- |
| The service returns to **Active** and then fails again | Auto Healing restored the process, but the underlying problem remains. | Review server resources, service configuration, logs, and external dependencies. |
| The service remains **Failed** after two recovery attempts | xCloud reached the retry limit and disabled automatic healing for that service. | Resolve the underlying service problem, then start the service manually or contact support. Auto Healing becomes available again after monitoring reports the service as active. |
| A service is visible in **Server Utilities** but is never restarted automatically | The service is installed but is not eligible for Auto Healing on that server stack. | Use the stack coverage table above and manage the service manually when it is outside Auto Healing coverage. |
| A manually disabled service starts again | The service is eligible and required, so a later monitoring cycle recovered it. | Do not use **Disable** as a persistent Auto Healing opt-out. Investigate the service requirement before stopping it. |

If the same service repeatedly becomes unavailable, review the related server task, check available server resources, and investigate configuration or dependency errors. [Contact xCloud](/contact/) if the failure continues.

## Limits and edge cases

-   Auto Healing applies only to eligible required services for the server's current stack and configuration.
-   OpenLiteSpeed and OpenSSH may appear in **Server Utilities**, but they are not currently Auto Healing-eligible.
-   PHP recovery follows separate required-version logic.
-   Auto Healing cannot correct every root cause, including exhausted server resources, invalid configuration, corrupted data, or an unavailable external dependency.
-   Manual **Reboot** and **Disable** actions are service-management controls, not evidence that an Auto Healing event occurred.

## FAQ

### Does Auto Healing apply to every service in Server Utilities?

No. **Server Utilities** lists installed services and their current status. Auto Healing applies only to eligible required services for the server's stack and configuration.

### Does an Active status mean Auto Healing ran?

No. **Active** only confirms that the service is currently running. The table does not expose the service's internal Auto Healing flag or prove that an automatic recovery occurred.

### How many times does xCloud retry a failed recovery?

xCloud allows up to two failed recovery attempts for an eligible service. After the second failure, the service remains **Failed** and automatic healing is switched off until monitoring reports the service as active again.

### Does Disable turn off Auto Healing permanently?

No. **Disable** stops the service manually at that time. If the service is eligible and required, a later monitoring cycle can start it again.

### What should I do if the same service keeps failing?

Review the related server task and service information, confirm that the server has sufficient resources, and investigate configuration or dependency errors. [Contact xCloud](/contact/) if the service continues to fail.