Guide›Troubleshooting
TroubleshootingIntermediate8 min

Build failed — what to do

Builds fail for a handful of well-understood reasons. This guide covers the most common failure modes, how to read the build log, and how to fix or retry each one.

Reading the build log

When a build fails, a red banner appears in the Build screen with a View log link. The build log is divided into three phases — knowing which phase failed tells you immediately where to focus:

1
Spec phase
Myndlab interprets your prompt and produces a structured specification. Failures here mean the prompt was unclear, contradictory, or requested something outside Myndlab's supported stack.
2
Code generation phase
The AI generates the full frontend, backend, and migration code. Failures here are usually caused by a dependency conflict, an unsupported library combination, or a very complex feature that exceeded the generation context.
3
Deploy phase
The generated code is built into a container, migrations are applied, and the app is started. Failures here are runtime errors — port conflicts, DB migration errors, missing environment variables, or a crash on startup.

Each phase is shown as a collapsible section in the log. The failing phase is expanded automatically and the first error line is highlighted.

Spec phase failures

Spec failures are always caused by the prompt. Common patterns and fixes:

1
Ambiguous or contradictory prompt
Example: "Use both PostgreSQL and MongoDB for the main data store." Fix: choose one. Rewrite the prompt to specify a single database for each data category.
2
Unsupported technology
Example: "Use Svelte for the frontend." Myndlab generates React + FastAPI + PostgreSQL apps. Requesting a different framework causes a spec failure. Use the Export as ZIP feature and adapt the code manually if you need a different stack.
3
Prompt too vague
Example: "Build something with AI." Add specifics — what kind of AI feature, what data it operates on, what the user interaction looks like.
💡
Tip.The most common fix for any failed build is clarifying the prompt. Copy the failed prompt, add a sentence explaining what didn't work or what you actually meant, and rebuild.

Code generation failures

Code generation failures are less common but can occur in specific situations:

1
Dependency conflict
Two requested libraries require incompatible versions of a shared dependency. The log will name the conflicting packages. Try removing or replacing one of them in a follow-up prompt.
2
Unsupported stack combination
Some combinations of features have known incompatibilities (e.g. certain real-time libraries alongside specific authentication patterns). The error message in the log will suggest an alternative approach.
3
Generation context exceeded
Very large, complex prompts requesting dozens of features in one build can exceed the generation context. Split the build into multiple prompts — start with the core data model and auth, then add features incrementally.

Deploy phase failures

Deploy failures happen after code generation succeeds. The generated code is correct, but something went wrong at runtime:

1
Port conflict
Another service is already bound to the expected port. This is rare in Myndlab's managed environment but can occur if you have multiple projects on a self-hosted plan.
2
Database migration error
A migration file contains a SQL error, or a migration tries to apply a change that conflicts with existing schema. The log will show the exact SQL statement that failed.
3
Container crash on startup
The app started but immediately exited — usually a missing environment variable or an import error. Check the container logs for the Python traceback or Node.js error.

Checking container logs

For deploy-phase failures, the container logs give you the raw process output — more detail than the structured build log. Access them from the Myndlab CLI:

bash
# Install the Myndlab CLI (once)
npm install -g @myndlab/cli

# Authenticate
myndlab login

# Stream container logs for your project
myndlab logs --project <your-project-slug> --tail 100

You can also view the last 200 log lines in the browser by opening the Build screen, clicking the three-dot menu in the top bar, and selecting Container logs.

The auto-retry button

After a build fails, Myndlab analyses the error and — if it has a high-confidence fix — shows a Suggested fix banner above the build log. The banner describes the proposed change in plain English. Click Apply fix and retry to let Myndlab amend the generated code and re-run the deploy phase without consuming an additional credit.

The auto-retry mechanism fires once per failed build. If the retry also fails, you will need to revise the prompt manually or contact support.

When to contact support

Most failures are resolved by prompt revision or the auto-retry. Contact support if:

1
The build fails after two retries with the same error
Copy the build ID (visible in the URL when the log is open) and paste it into the support chat.
2
Credits were deducted for a build that should not have charged
Spec-phase failures are never charged. If you were charged for a spec failure, that is a billing error — include the build ID and the transaction timestamp in your support message.
ℹ
Note.Credits are not deducted for builds that fail in the spec phase. Partial credits are deducted if the failure occurs mid code-gen — the credit cost is proportional to how far generation progressed before the error.