GuidesOnly show guides for your app
GuidesGuidesRead the deployment log first, then fix the handful of usual causes — wrong branch, revoked access, a private repo linked by URL, or a "successful" deploy that changed nothing.
A Git deploy can go wrong two ways: it fails outright with a red status, or it reports success while your server somehow runs yesterday's code. Both are readable straight from the Git page. This guide walks the deployment log and the short list of causes behind each.
| At a glance | |
|---|---|
| You need | A server with a repository linked and deploying — see Deploy from Git |
| First move | Open the Git page → Deployments tab and read the log |
Open the Git page and switch to the Deployments tab. It lists every deploy with a status; a failed one shows in red. Click it and read its log. Most of the time the log names the cause outright — branch not found, authentication failed, a post-deploy command that errored. Read that first; the rest of this guide is what it usually says.
master → main, or the reverse) or deleted the one you linked, the deploy can't find it. Open the Code tab and set the deploy branch to one that exists.The deploy is green, yet the server acts unchanged. Usually one of these:
src/ or app/, the application won't find it at the root. Point the Main file (Node) or App py file (Python) variable at the right path in Settings, or restructure so the entry file lands at the root — see the layout note in Deploy from Git.⚠️ Heads up: Deploys copy and overwrite — they never delete. It's the same behavior that keeps your
.envsafe across deploys; it just cuts both ways.
You pushed, but the Deployments tab shows no new entry. Whether a push deploys depends on how the repo is linked:
So if you linked by URL and expected pushes to deploy instantly, that's the mismatch — connect the account for webhooks, shorten the scheduled-pull interval, or just deploy manually. Auto-deploy on push sets this up properly.
💡 Tip: When a deploy ships broken code and you need the site back now, don't debug live — roll back.
The deployment history lets you pin a deployment to a specific commit, so pin the last one that worked. Your server returns to that known-good code while you fix the problem on your own time, then deploy again.