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.
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 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 — it is charged when a build starts and automatically refunded if the build fails. A failed deployment does not trigger a build refund.
Credits consumed due to platform-level deployment failures are eligible for a refund. Contact support with:
- Your account email
- Your 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 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.