Troubleshooting6 min readPublished September 20, 2026Updated September 22, 2026
Why isn't my GitHub deployment updating?
Four things can hold a change back: it is on a branch nobody deploys, the deployment failed, the deployment succeeded but was not promoted to your domain, or you are looking at a cached copy. Check them in that order.
The problem
The commit exists on GitHub. The live URL still serves the previous version, sometimes hours later.
What it means
The chain from commit to domain has broken at one link. Each link is individually easy to check, and each has a distinct signature.
Common causes
| Cause | Signature |
|---|---|
| Wrong branch | No deployment was created at all |
| Failed build | A deployment exists and is marked failed |
| Not promoted | A successful preview deployment, domain unchanged |
| Integration lost access | No deployments since a specific date |
| Browser or CDN cache | New content in a private window, old in yours |
How to diagnose it
- 1Open the deployment list and find the newest entry. Note its commit hash.
- 2Compare that hash with the commit you expected.
- 3If the deployment failed, open the build log and read the first error, not the last.
- 4If it succeeded, confirm which deployment your domain points at.
- 5Open the site in a private window with cache disabled to rule out caching.
How to fix it
- Merge the branch into the one that deploys, or change which branch deploys.
- Fix the build error and push again.
- Promote the successful deployment to production.
- Reconnect the integration if its access was revoked or the repository was renamed.
- Purge the cache, or wait out the cache lifetime, after confirming the deployment is correct.
What AI may have done
- Committed to a working branch rather than the deploying branch.
- Introduced a type error that only the production build rejects.
- Added a dependency without updating the lockfile the clean build installs from.
- Changed a build script or output directory setting.
How to verify the fix
- 1Confirm the newest successful deployment's commit hash matches your change.
- 2Confirm the domain points at that deployment.
- 3Load the site in a private window and check for the visible change.
- 4Check a non-cached route, such as an API endpoint, if the page still looks stale.
How to prevent it
- Know which branch is your production branch and say so in the readme.
- Watch for deployment failure notifications rather than discovering them later.
- Run the production build locally before large changes.
- Use preview deployments so a failure never blocks the live site.
Frequently asked questions
- How long should a deployment take?
- Usually one to three minutes for a small app. Much longer usually means a slow install or a large build.
- Can I force a rebuild without a code change?
- Yes, most platforms offer a redeploy button, which is useful after changing an environment variable.
- Why does one page update and another not?
- Different caching rules. Static pages can be cached far more aggressively than dynamic ones.
Practice this in MessyDev
Reading it once helps. Doing it once sticks. These are the hands-on parts of MessyDev that cover the same ground.
Keep going
- How GitHub works with AI coding toolsRepositories, commits, branches and pull requests — what they are, and what changes when an AI tool is the one writing the commits.
- What happens when you deploy an app to Vercel?From commit to live URL: install, build, output, edge and server functions, environment variables and why the production build is stricter than your laptop.
- Why does my app work locally but not after deployment?The differences between your machine and a deployment — configuration, case sensitivity, build strictness, real users — and how to find which one bit you.