Deployment not found
Your code is fine. The pointer to it is gone.
DEPLOYMENT_NOT_FOUND is a modern-hosting error with an old-fashioned cause: your domain is aimed at a deployment that no longer exists. The code didn't break — the arrow pointing at it did. That's usually good news, because arrows are quick to re-aim.
Diagnosis within one business day (Mon–Fri). Flat quote before any fix.
What’s actually happening
Platforms like Vercel and Netlify serve immutable deployments — every push builds a new one, and your domain points at whichever is 'current.' DEPLOYMENT_NOT_FOUND means the domain resolved to the platform correctly, but the specific deployment it references was deleted, expired, or lives in a project the domain no longer belongs to. The site isn't down in the classic sense; it's orphaned.
The orphaning routes are predictable: someone deleted old deployments (including the one production pointed at), the project moved between personal and team accounts and the domain assignment didn't follow, a preview URL got shared as if permanent, or billing lapsed and the platform quietly released the resources. Each has a different fix, and all of them are faster than the panic suggests — usually re-assigning the domain or triggering one fresh deployment.
The usual causes, ranked
After twenty-seven years of these calls, the odds are well mapped. Start at the top.
Deployment cleanup took production with it
Bulk-deleting old deployments and catching the one the domain referenced. The most common self-inflicted route.
Project or team transfer orphaned the domain
Moving a project between accounts without re-attaching the domain — it stays aimed at the abandoned copy.
A preview URL treated as permanent
Preview deployments expire by design. If the 'site' someone bookmarked was a preview link, it was always going to vanish.
Billing or account state released resources
Lapsed payment or a suspended account letting deployments expire while DNS keeps pointing at the ghost.
What you can safely try first
Nothing below can make things worse — that’s the selection criterion. Anything riskier belongs in professional hands, on a backup.
- 1
Check the platform dashboard first
Does the project exist? Does it show a production deployment? Is your domain listed under it? Ninety seconds in the dashboard usually names the failure route.
- 2
Confirm which account owns the domain
In team setups, the domain often belongs to a different scope than the project. Look for it under both personal and team accounts before assuming it's gone.
- 3
Trigger one fresh deployment
If the project is intact, redeploying from the connected repo mints a new deployment and re-aims production at it. Often the entire fix.
Stop and call when…
- The connected Git repository is missing or the connection is broken — that's a deeper unwind
- The domain shows in no account you control — possession questions beat configuration questions
- Environment variables and secrets went missing with the project — the redeploy will build but the app won't run
From there it’s our job: a look within one business day, flat quote, and the $249 flat repair covers most cases of exactly this.
Site Down or White Screen — buy it now, skip the hunt.
500 and 502 errors, a white screen, a database connection error, a site that broke after a PHP update.
Back online first, then the cause. A full backup once it is up, and a note on what failed and how to keep it from happening again. We start within one business day (Monday–Friday) of payment. Full refund if we can't fix it.
Questions we hear a lot.
Is my code lost?
Almost certainly not. Code lives in your Git repository; deployments are disposable copies built from it. DEPLOYMENT_NOT_FOUND means a copy vanished — the source is wherever it always was, ready to build a fresh one. The exception worth checking: environment variables, which live on the platform, not in Git.
Why would a hosting platform delete my deployment?
By design, deployments are cattle, not pets — previews expire, old builds get pruned, and resources release on billing lapses. The platform assumes the current production build is re-creatable from your repo at any moment, which is true right up until the domain points at a build that got pruned.
What does the $249 fix cover on a modern stack?
Untangling the account/project/domain triangle, restoring or re-creating the production deployment, re-attaching the domain, verifying environment variables survived, and a smoke test of the live site. We build on this stack daily — this is home turf, not exotic territory.
Related symptoms & help
Errors travel in packs. If this one visited, check its friends.
- 404 ErrorsThe classic-hosting cousin.
- SSL ProblemsThe other 'domain vs platform' tangle.
- Emergency RepairIf this is production, right now, jump the queue.
- Custom Web AppsThe stack we build on daily.
- Website RepairThe whole bench.
- DeindexedDeindexed by Google
- High INPHigh INP score
- Image Upload ErrorHTTP error uploading
Re-aim the arrow. Get the site back.
Send the symptom, get a look within one business day and a flat quote from the developer who's fixed this exact thing more times than either of us can count.