# See Why a Git Deploy Failed, Right From Your xCloud Dashboard (v2.9.8)

> Git deploy failed? xCloud v2.9.8 shows the reason on your Deployments page, alerts you once per reason and retries deploys that never reached the server.

If your Git deploy failed on xCloud, you no longer have to search a raw log for the reason. Since v2.9.8, the site's **Deployments** page shows a plain summary, the failed step, how long the site has been failing, and the output around the first error.

Git deploys are meant to be the quick part of shipping, which is the whole idea behind [**One Click Git Deploy**](/one-click-git-deploy-ship-any-project-the-fastest-way/). A failed one used to break that rhythm: a long log, one more email, and a hunt for the line that matters.

This post covers what you now see when a deploy fails, when you get an alert, what happens when a deploy never reaches your server, and what this release does not do.

## **TL;DR**

- **The reason is on the page:** open **Deployments** and read the **Deploys of this site are failing** notice.
- **You see where it stopped:** the failed step is **Pull latest code**, **Deploy script**, **Build** or **Start**.
- **Fewer alerts:** you hear when a site starts failing or fails for a different reason, not on every repeat.
- **Shorter alerts:** email, Slack, Telegram, WhatsApp and in-app alerts carry the short cause, not the whole log.
- **Automatic retries:** a deploy that never reached the server is tried again after 2, 5 and 8 minutes.
- **The limit:** xCloud shows you the reason. You still fix the deploy.

## **Your Dashboard Now Starts at the First Error**

The most useful line in a failed deploy is usually the first error, not the last line of the log. So the notice shows about 40 lines of output around that first error, and hides values that look like passwords and keys.

Here is what changed in v2.9.8:

| When a Git deploy fails | Before | Now |
|---|---|---|
| **Finding the cause** | Read the full log | Read the notice on **Deployments** |
| **Email** | The full deploy log | The summary, failed step and output lines |
| **Repeat failures** | An email for every failed deploy | One alert per reason, repeats are counted |
| **Server could not be reached** | Reported as a failed deploy | Tried again after 2, 5 and 8 minutes |

## **Why a Failed Git Deploy Is Hard to Read**

A deploy log records everything that ran, in order. Successful commands, warnings and the real failure all look alike, so you end up reading from the bottom and working backward.

Repeat failures make it worse. A site that keeps failing can fill your inbox with the same long log, and the one new error is easy to miss.

Then there are failures that have nothing to do with your code. If xCloud could not reach your server, nothing ran at all, but it could still look like your deploy was broken.

## **The Reason on Your Deployments Page**

Open the site and click **Deployments** in the site menu. You can also click **View Deployments** in the failure email. The [**Deployments page**](/docs/view-git-deployments-in-xcloud/) shows the notice above the list of deployments, and it stays until a deploy succeeds.

![The Deploys of this site are failing notice on the xCloud Deployments page, showing the summary, failed step and output around the first error](/_landing/blog/why-your-git-deploy-failed-on-xcloud-image-1.png)

In this example site, the build command names a script that does not exist in `package.json`. The notice says so in one sentence, then shows the npm error underneath it.

| Part of the notice | What it tells you |
|---|---|
| **Summary** | The cause in plain words |
| **Failed step** | Where the deploy stopped. It is left out when no step can be named |
| **failing since** | How long the site has been failing |
| **failed 2 more times with the same reason** | How many repeats there were. It appears only after a repeat |
| **Output lines** | About 40 lines around the first error |

The failed step tells you where to look next:

| Failed step | Where to look |
|---|---|
| **Pull latest code** | The branch name, or your deploy key or Git provider connection if access was refused. See [**Clone fails**](/docs/troubleshooting-git-deployments-stuck-failed-or-not-triggering/#clone-fails) |
| **Deploy script** | The command named in the summary. Edit it under **Deploy Script** on the site's **Git** page |
| **Build** or **Start** | Your build and start commands, covered in the [**Git deployment troubleshooting guide**](/docs/troubleshooting-git-deployments-stuck-failed-or-not-triggering/) |

If GitHub refused access, its guide to [Permission denied (publickey)](https://docs.github.com/en/authentication/troubleshooting-ssh/error-permission-denied-publickey) explains that error in more depth. Once you have made the fix, click **Deploy Now**. If you see **Check & Deploy** instead, click that.

On the free plan there is no **Deploy Now** button. Push a commit to the site's branch (**Enable push to deploy** must be on), or change a setting on the **Git** page and click **Save and deploy**.

## **Fewer, More Useful Alerts**

Your team hears about a failing site by email and through any channel you have connected, such as [**Slack**](/docs/configure-slack-integration-in-xcloud/), Telegram or WhatsApp. Alerts now carry the short cause and a link back to **Deployments**.

Emails include the summary, failed step and output lines. Slack, Telegram, WhatsApp and in-app alerts include the summary, the failed step and up to 10 lines of the cause.

![A chart of when xCloud sends a deploy failure alert: when a site starts failing or fails for a different reason, but not on a repeat or a recovery](/_landing/blog/why-your-git-deploy-failed-on-xcloud-image-2.png)

| What happens | Do you get an alert? |
|---|---|
| A site starts failing | Yes |
| It fails again for the same reason | No, the count in the notice goes up |
| It fails with a different kind of error | Yes |
| The same kind of failure has a new reason | Yes, at most once an hour per site |
| A deploy succeeds | No, the notice goes away |

One thing to plan around: there is no recovery alert. If you want to know a site is healthy again, check **Deployments**.

## **Deploys That Never Reached the Server Are Retried**

A deploy that could not reach your server does not count against your site, because nothing ran there. You get no failure alert, and this attempt adds no failure notice.

Instead, xCloud tries the same deploy again after 2 minutes, then 5, then 8. That is 15 minutes in all, and a newer deploy from you or a push replaces the retry.

![A timeline of the three automatic retries, at 2, 7 and 15 minutes after a deploy could not reach the server](/_landing/blog/why-your-git-deploy-failed-on-xcloud-image-3.png)

The catch worth knowing: between tries, the attempt still shows as **Failed** in the list, and its log says "Nothing ran on the server". That can look alarming, so check the log before you start changing settings.

If the third retry fails too, your team gets one server disconnected notice, at most once per server in 6 hours. Check that the server is online and connected, then deploy again.

## **What This Does Not Do**

The notice is a shortcut to the reason, not a repair tool. These limits are worth knowing before you rely on it:

- **It does not fix the deploy.** You change the code or setting and deploy again.
- **The summary can be wrong.** It comes from fixed rules that match known errors, so an earlier warning can mislead it. Trust the error line just above where the deploy stopped.
- **Some failures show no detail.** If the summary says only "The deploy failed.", the cause is not in your site's code or settings, and the alerts leave out the cause too. Contact support and name the site.
- **It covers deploys that ran.** A push that never starts a deploy, or a deploy stuck in progress, needs the checks in the [**troubleshooting guide**](/docs/troubleshooting-git-deployments-stuck-failed-or-not-triggering/).
- **Nothing to undo.** The notice clears itself after the next successful deploy. There is no setting to turn on.

## **For Developers: Ask From the API or Your AI Agent**

You can read the same failure details from a script or an AI agent. `GET /sites/{uuid}/deploy-diagnosis` (MCP: `sites.deploy-diagnosis`) returns a `verdict` object with the failed `step`, `cause_excerpt`, `commit_sha` and `created_at`.

While a retry is coming, `deploy_state` stays `in_progress`, so keep polling instead of starting another deploy. The fields and permissions are in the [**Public API and MCP guide**](/docs/deploy-git-projects-with-xcloud-public-api-and-mcp/).

## **Also in v2.9.8**

A few smaller fixes shipped alongside this. The [**v2.9.8 changelog**](/changelog/v2-9-8/) has the release notes.

| Area | What now works |
|---|---|
| **Lovable** | Lovable projects built with TanStack Start now get their build and start commands filled in for you. If a project's setup can't use them, a warning asks you to enter the commands yourself. See [**deploying Lovable apps**](/docs/deploy-lovable-applications-with-xcloud/) and [**Lovable hosting**](/lovable-hosting/) |
| **Private repositories** | **Verify connection** for a deploy key no longer fails on very large repositories. Connect yours through a [**Git provider**](/docs/how-to-integrate-a-git-provider-with-xcloud/) or a deploy key |
| **Redis Object Cache** | Installing it no longer turns off a working cache on sites that are not in English. Read more on [**Redis object caching**](/advanced-redis-object-caching-for-wordpress/) |
| **Teams** | Team admins can manage members again. If a member still can't be changed, **Change Role** and **Delete** show you why. See [**team roles and permissions**](/docs/team-roles-permissions-in-xcloud/) |
| **WordPress core updates** | A plugin crash during a WordPress update no longer leaves the update stuck |

## **Ship With the Reason in Plain Sight**

Try it on your next deploy. Connect a repository with [**One Click Git Deployment**](/one-click-git-deployment/), push your code, and open **Deployments** whenever a deploy goes wrong.

**Compare plans on the [pricing page](/pricing/).**

Next time a deploy fails, start at the notice instead of the log. Read the failed step, fix that one thing, and deploy again. Your time is the hidden cost of every failed deploy, so start where the reason is.

If you have found this blog helpful, feel free to [**subscribe to our blogs**](https://xcloud.host/blog/) for valuable tutorials, guides, knowledge, and tips on web hosting and server management. You can also join our [**Facebook community**](https://www.facebook.com/groups/xcloud.community) to share insights and engage in discussions.

## Frequently Asked Questions

### **Why did my Git deploy fail on xCloud?**

Open the site and click Deployments. The Deploys of this site are failing notice shows a plain summary, the failed step and the output around the first error. Use the failed step to choose what to fix, then deploy again.

### **Does xCloud fix a failed deploy for me?**

No. xCloud shows you the reason and where the deploy stopped. You still fix the cause, such as a missing script or a rejected deploy key, and deploy again.

### **Why did I get only one alert when my deploy failed several times?**

You are told when a site starts failing or fails for a different reason, not on every repeat. Repeats of the same reason only add to the count in the notice. No alert is sent when the site recovers.

### **Why does a deploy show Failed in the list with no failure notice?**

It may not have reached the server. Nothing ran there, so it does not count against your site, and its log says Nothing ran on the server. xCloud tries again after 2, 5 and 8 minutes, and a newer deploy replaces the retry.

### **Can the summary point at the wrong cause?**

Yes. The summary comes from fixed rules that match the output against known errors, so an earlier warning can mislead it. If the summary and the output disagree, go by the error line just above the point where the deploy stopped.