Skip to main content
Start with the logs. Most problems show up there first.
  • Mist desktop app: click Logs. The Production tab shows the live app. The Local tab shows your computer.
  • CLI: fluid mist logs --tail streams the live app’s build and runtime logs.
You can also ask Mist, for example “Why did my app crash?”. Mist reads the logs and tells you what it finds.

​
Creating the app fails

If an app shows Failed, it was rolled back. Create a new one.

​
The app stays in provisioning

An app moves to live once its first deployment starts. Check its state with fluid mist show. If it stays in provisioning for more than a few minutes, run fluid mist deployments to see whether the first deployment failed.

​
A publish or build fails

1

Read the build log

Open Publish output in Mist, or run fluid mist logs --deployment <id> with the ID from fluid mist deployments. Look for the first error.
2

Reproduce it locally

Run the same checks the build depends on:
3

Fix and publish again

Fix the error, then publish again.
Mist tries one fix on its own when a publish fails. For each reason Mist reports, see If a publish fails. To go back to the last version that worked, see Roll back.

​
The live app crashes or returns errors

Open the Production logs, then load the failing page again. The request’s error shows up as it happens. Errors your code logs with console.error show up there too. If a change works locally but not live, check what differs in production:
  • Data. Production has its own database. Rows you created locally aren’t there.
  • Environment variables. A variable in your .env.local must also be set on the app. See Add your own environment variables.
  • Embedding. A page that works on its own can still be blocked inside Fluid. See The embed won’t load.
If the first request after a quiet period is slow, check the app’s Compute setting. Standard serverless sleeps between requests, so the first request waits for the app to start. Fluid Compute keeps it warm. See Compute.

​
Database errors

Open /api/health on the app. It returns {"db":"ok"} when the database answers, or a 503 with the error. To start your local database over, stop the app and delete the local.db folder. It’s created again on the next npm run dev. You can browse the app’s local and production data in Mist, read-only. See Databases.

​
Environment variable problems

​
Webhooks are rejected

The template’s webhook route returns these errors. Find the message in the production logs. If installs never reach the app, run fluid mist droplet repair. It fixes the droplet’s embed and lifecycle webhook URLs when they don’t match the app. Every webhook the app receives is saved in its webhooks table, with any error. Query it in Databases to see what arrived.

​
The embed won’t load

Verifying a viewer also needs the settings scope on the droplet installation. Without it, the store lookup is refused and the page returns 401.

​
A custom domain doesn’t work

See Connect a custom domain.

​
Restore a deleted app

A deleted app is kept for 15 days. Until then, you can restore it with its code, database and settings intact.
You can also use Cancel a pending teardown in the API. The Mist desktop app doesn’t have a restore button yet. After 15 days, Fluid permanently deletes the app’s repository, database and hosting. It can’t be restored.

​
Get help

If you’re still stuck, contact Fluid support. Include the app’s slug, what you did and the error from the logs.
Email Fluid support at help@fluid.app. The Getting help page lists what to include in your request.