Deployment errors are frustrating, especially when the build completed successfully but the app won't go live. This article explains what the most common deployment failure patterns look like and what to do in each case — so you can stop the problem from getting worse and get back on track as quickly as possible.
Understanding deployment errors
A "deployment error" or "go live failed" message means that your app's code was built successfully, but the step that publishes it to the live internet did not complete. The build and the deployment are two separate steps — it is possible (and common) to see a successful build followed by a failed deployment.
Because the error can have several different causes — some temporary, some requiring support intervention — the most important thing to do first is identify which pattern you are in.
Build succeeded, but the app won't go live
This is the most common deployment failure. The chat shows a completed build, but the app either shows an error, loads a previous version, or doesn't respond at all.
What to try first:
- Wait 60 seconds and reload. Deployments take a moment to propagate — sometimes the app is live before the UI reflects it.
- Check the live URL directly rather than the draft preview. The draft and the live version are separate; a deployment error only affects the live version.
- Try opening the app in a private/incognito window to rule out a caching issue.
Build is taking too long or seems frozen
Builds typically complete within a minute or two. If yours has been running for several minutes without completing, try sending "are we stuck?" to the AI. This usually triggers it to either finish or fail, so you are not left waiting indefinitely.
If the build fails after that, revert to the last working version and try again — this time breaking your request into smaller, more focused changes. Large or complex prompts are more likely to hit build limits or cause the builder to get stuck.
If the problem persists after waiting, do not trigger a new build. Retrying a failed deployment by requesting another build will consume more credits and may not resolve the underlying issue. Instead, contact support with:
- Your project name
- The version number shown in your chat history (e.g. "Version 174")
- The exact error message you saw
Credits charged for a failed deployment
Going live costs 4 credits and is charged when deployment is triggered — not when it completes. If the deployment fails after being triggered, those credits are still spent. The 2-credit build charge is separate and only applies when the AI successfully generates and compiles your app, so a failed build does not cost credits. A failed deployment, however, does.
Credits consumed due to platform-level deployment failures are eligible for a refund. Contact support with:
- Your account email
- Your project name or project ID
- An approximate count of failed deployment attempts, or the version number range where the failures occurred
Support will review your deployment history and return credits for failures that were outside your control.
All your apps are failing, not just one
If deployment errors are happening across multiple projects simultaneously, this is likely a platform-level incident rather than a problem with your specific app.
Before submitting a ticket, check the #general-chat channel in the Caffeine Discord — the Caffeine team posts status updates there when a known incident is active. If an incident has been announced, the team is already working on it and submitting a ticket will not speed up the resolution.
If there is no announcement and multiple apps are failing, contact support and mention that it affects more than one project — this helps the team triage faster.
When your project is truly stuck
If you have tried reverting and re-prompting repeatedly and the project remains broken, there is an escape path: export your project to GitHub, fix or clean up the codebase using an external tool or developer, and reimport when project import becomes available. This is the recommended path for projects that have accumulated too many errors for the AI to resolve on its own.
To reduce the chances of getting into this situation in the first place, keep your prompts small and focused. Large changes — especially ones that restructure the backend or change data relationships — are more likely to exceed build limits or produce errors the AI cannot self-correct.
Frequently asked questions
Should I keep retrying if deployment keeps failing?
No. Retrying by triggering new builds will consume credits without fixing the underlying issue. Stop and contact support once you have confirmed the problem is not a temporary delay.
How do I find my version number?
Your version number is shown in the chat history next to each completed build — for example, "Version 172 is live." Scroll back through your chat to find the most recent version that appeared to deploy successfully.
Can I revert to a version that was successfully built but never went live?
You can use the Revert to version N button in your chat history to restore your draft to any previous build. Keep in mind: once you have gone live, you can only revert to draft versions that were created after your last live deployment — not to earlier drafts. After reverting your draft, you will still need to deploy it.
Will I lose my data if I redeploy?
No. Your app's data is stored separately from its code and is preserved across deployments and reverts.
What information should I include when contacting support about a deployment failure?
Include: your project name, the version number(s) involved, the error message you saw, and whether the issue affects one project or multiple. Screenshots are helpful but not required.