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.
Understanding deployment errors
Caffeine's publishing pipeline runs in two distinct steps: first it builds your app (generates and compiles the code), then it deploys it (publishes it to the live internet). Each step can fail independently:
- A build failure shows a message like "Something went wrong while building your app" — with a wrench icon. See When Builds Fail for what to do.
- A deployment failure means the code was built successfully, but the publishing step did not complete. A "Go live failed" message indicates a failure when promoting your app to its permanent live address. Failures during draft builds (the preview you see while iterating) are handled directly by the AI without a separate system message.
This article covers deployment failures — the second step.
How Caffeine handles deployment errors
When a deployment fails, the error flows back to the AI automatically. The Composer — the agent that coordinates your build — reads the error message, attempts to fix the underlying issue, and retries the deployment once. In many cases, deployment errors are resolved without any action from you.
The Quality agent also captures console logs and takes screenshots during the build process. Runtime errors — such as uncaught exceptions, failed network requests, and rendering issues — are flagged and can be addressed in a follow-up build wave before deployment is attempted.
For draft deployments (the preview built during each iteration), the AI agent receives the failure details directly and communicates back to you in the chat. No separate error message is shown — the AI handles the conversation.
If a Go Live deployment fails after the automatic retry, Caffeine reports the failure to you with a "Go live failed" message and details about what went wrong. If the failure happens during your very first go-live attempt, the Go live button is re-enabled in the header so you can try again without needing to take any additional steps.
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 few minutes. Deployments are given up to 10 minutes to complete — for most apps this is much faster, but larger apps or slower conditions can take longer. If yours has been running for several minutes without completing:
- Check the build progress panel to see which task is currently running
- Send "what's the current status?" or "are we stuck?" to the AI
- Use the stop button to halt the build if you want to try a different approach
If the problem persists, 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 ID
- The version number shown in your chat history
- The exact error message you saw
Credits charged for a failed deployment
Going live costs 4 credits and is charged when you click Go live — not when deployment completes. The build charge is separate — credits are held when a build starts.
You are not charged when a build fails. Held build credits are released back to your account automatically. No further action is needed on your side.
A successful build costs credits even if you are not happy with the result. Caffeine does not release credits back when you dislike the output of a build that completed successfully.
If Go Live could not start after you clicked the button — for example, the deployment job never began — deployment credits are released back to your account automatically. No further action is needed on your side.
If you see a Go live failed message in chat, the deployment ran but did not complete. The Go Live charge typically still applies. Check Profile avatar → Credit usage for your transaction history. If the charge looks wrong, use Profile avatar → Get help and include your project ID and the version number involved.
When your project is truly stuck
If the deployment keeps failing after reverting and re-prompting, you have two escape paths:
- Take offline and publish fresh. If you are willing to permanently lose all live data, open project settings → More → Take offline and confirm. This tears down your live canisters entirely. Once offline, click Go live to deploy your current draft as a brand-new installation — the schema compatibility check is bypassed because there is no existing canister to upgrade against. This is particularly useful when a breaking backend change makes the draft permanently incompatible with what is installed on the live canister.
- Export, fix, and reimport. Export your project to GitHub, fix or clean up the codebase using an external tool or developer, then use Import from GitHub in project settings to bring the corrected code back into Caffeine as a new draft. GitHub Import requires an active paid subscription. See Syncing your Project with GitHub for full instructions.
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. Caffeine now automatically retries a failed deployment once after attempting a fix. If that retry also fails and you're told about it, retrying manually 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 two places: next to each completed build in your chat history, and on the version badge in the top-right corner of the app preview panel. Click the version badge to open the version history, which lists all your previous versions with timestamps.
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 ID, 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.