Troubleshooting

Start by identifying whether the issue is in development Preview, the build process, the production release, or an external service. They have different remedies.

Troubleshooting is easier when you first name the layer that is failing. A Preview loader belongs to the development environment. A completion card belongs to the build. A custom-domain error belongs to production or DNS. A payment-provider response belongs to an external integration. Starting in the right layer prevents broad restarts and unrelated rebuilds.

Change one thing at a time and record the result. A narrow observation—project, time, route, action, and message—is more valuable than several speculative fixes performed together. Use the least disruptive control that directly matches the symptom.

Example: If Preview is blank but the published domain works, investigate the development app. Do not roll back production.

Preview is warming up

A sleeping development environment needs time to start. Keep the project page open while the warm-up message changes. The Preview should transition automatically.

If the environment reports ready but the loader never clears:

1. Wait for the current warm-up request to finish.
2. Refresh the browser once.
3. Check Development Cloud for the selected project.
4. If it repeats, note the project ID, time, browser, and loader message for support.

Repeated rapid refreshes do not start the server faster and can make diagnosis harder.

Normal warm-up has a visible progression: the project request wakes the server, the app becomes reachable, and the loader gives way to Preview. The exact time depends on the environment, but the important signal is whether the state advances. A server marked Online with a loader that never transitions is different from a server still starting.

On mobile, leave the Preview tab active while it transitions. If a single refresh loads the app only after the server is already Online, record that detail because it points to the browser transition rather than a missing project.

Example: “Development Cloud became Online after 35 seconds. Safari kept showing Getting everything ready for another minute, then one refresh loaded the app.”

Preview is blank or shows an error

• Open Terminal/System for the current runtime message.
• Confirm the route in the Preview path field.
• Send one focused Build prompt with the error and expected behavior.
• Include a screenshot and device size for visual failures.
• Do not ask for unrelated redesign work in the same repair.

First decide whether the browser received an empty application, an explicit runtime error, or a refused connection. Copy the exact non-secret message and route. Confirm whether the same route works in another viewport or browser before treating it as a global failure.

If the app is still building, wait for completion so you do not diagnose a temporary intermediate render. If the completed version is blank, compare the completion evidence with the interactive Preview and send one repair request that preserves any work already proven correct.

Example: “After v5 completed, /leads is white in Preview while / works. Terminal shows a component import error. Repair /leads only and keep the completed dashboard.”

A build looks quiet or stalled

Some provider or tool steps take longer without producing customer narration.

• Do not submit the same build repeatedly.
• Check whether the stop control is still active and whether new durable progress appears.
• If you sent the wrong request, Stop it.
• If the task reaches an actionable failure, retry the same focused request or use the suggested model option.
• Record project ID, job/time, last visible phase, and whether any files or preview state changed.

Quiet is not automatically stalled. Image generation, provider reasoning, package work, or mechanical verification can take time without frequent public narration. A real report should distinguish elapsed time from lack of durable progress, tool receipts, status changes, or a final response.

Do not create a second active request for the same outcome. If you stop, understand that Stop ends the current turn rather than pausing it. Preserve the last visible phase and time so support can correlate the customer view with server evidence.

Example: “Project 345 stayed on Thinking about it for 12 minutes. The Stop button remained active, no new version appeared, and Preview did not change.”

The answer or build request was not accepted

Keep the page open long enough for the request response. If text remains in the composer and no user message appears, the submission was not accepted; retry once after confirming connectivity. If the user message appears, do not send a duplicate.

The appearance of your message in Chat is the clearest customer-facing receipt. A temporary spinner without a user message can mean the browser request did not finish. A user message followed by active status means Mango9 accepted the turn, even when the next progress update takes time.

Example: The prompt remains typed in the composer after the network reconnects and never appears in Chat. Send it once. If it already appears as a user bubble, wait for that turn.

Cannot publish

Review the exact message:

• Plan required: activate a publishing plan.
• Latest build not ready: review the build outcome and finish the focused repair.
• Connect database: add a reachable production Postgres connection.
• Operation already running: wait for the active publish/restart/rollback.
• Environment variable missing: add it and restart/republish as directed.

Resolve the named gate through its product control. Build chat cannot activate a plan, invent a production database, or override a protected concurrent operation. After fixing the requirement, return to the same project and resume Publish instead of rebuilding unrelated code.

Example: “Connect database” on a CRM is resolved under Integrations or the publish database step. Asking Build to remove the database check would create a less reliable app.

Database connection fails

• Copy the URI exactly from the provider.
• Confirm the provider allows network access from the production environment.
• Confirm TLS/SSL requirements in the connection string.
• Check that the database and user still exist and the password was not rotated.
• Save the new value under the expected variable name.
• Use the provider dashboard for database availability and backups.

Test the same credential in the intended project and environment. A valid connection saved in the account vault can still be unlinked from the project, scoped to the wrong database, or blocked by provider network policy. Rotate the password only when evidence says the credential is wrong or exposed.

Do not paste the URI into Chat or support. Report the provider name, variable name, project, test result, and redacted error category.

Example: “The saved Neon production credential is linked to Project 354, but Test returns TLS required. The secret value is not included.”

Custom domain stays on Pending DNS

• Compare the hostname and target with the record Mango9 shows.
• Remove conflicting records for the same hostname.
• Remember that apex and www are different hosts.
• Allow resolver cache time.
• Re-run the DNS check after the record resolves publicly.

HTTPS is issued after the correct production mapping resolves; a draft project cannot receive a domain assignment.

Check DNS from the provider where the domain is managed, not only from the browser cache. Verify the exact hostname—apex and www are distinct—and compare it with the target Mango9 displays. Conflicting A, AAAA, or CNAME records for the same host can send different visitors to different places.

Example: app.example.com points correctly, but example.com still points to an old server. Connect or redirect each hostname intentionally instead of waiting for one record to change the other.

A teammate cannot see a control

The role may not have that permission. Ask an account owner/admin to review Team roles. Do not share an owner's password to work around permissions.

Confirm the person is a member of the intended account, has access to the selected project, and has the action permission. Those are separate checks. A teammate may see a project card but remain unable to delete, publish, view billing, or manage credentials by design.

Example: A Builder opens the CRM but receives Forbidden on Delete. The owner should review project ownership and delete permission rather than loaning the owner account.

Billing looks stale

Refresh Billing after a settled payment or usage update. Wallet top-ups appear after the charge succeeds. Production usage can be aggregated by project and billing period rather than appearing as an instant per-second line.

Identify whether you are waiting for a card payment, wallet transaction, subscription invoice, or production-usage aggregation. They settle through different paths. Do not repeat a purchase while the first payment is still processing.

Example: A successful card confirmation returns to Mango9 before the wallet transaction refreshes. Wait for settlement and refresh Billing once; report the payment time if the credit never appears.

What to send support

Include:

• project ID and project name;
• approximate time and timezone;
• page/route;
• the exact action performed;
• expected and actual result;
• screenshot or short screen recording;
• browser/device;
• error text without credentials.

Never send passwords, database URIs, API keys, session cookies, or one-time login links.

Put the evidence into a reproducible sentence: “On this project and route, at this time, I performed this action and saw this result.” Add one safe screenshot or recording when the behavior is visual. Mention any single recovery step already attempted so support does not ask you to repeat it unnecessarily.

Example: “Project 358, /contacts, Aug 6 at 3:29 PM Pacific, iPhone Safari. Opening the model menu placed it behind the composer. Refresh did not change it. No credentials are included.”