Preview troubleshooting

First identify which surface failed

The development preview, the published application, and the static image on a project card are different surfaces. An error on one does not prove that all three are broken.

Record the selected application, page path, exact error, and approximate time. If the project contains several applications, check that you selected the one with the user-facing preview.

What do gateway errors mean?

504 Gateway Timeout means a gateway did not receive the upstream response it needed before its deadline. It does not, by itself, identify whether the cause is the application, its dependencies, or platform routing.

503 Service Unavailable can appear while an application is starting or unavailable. 502 Bad Gateway indicates a proxy or upstream protocol failure. Record the actual code instead of treating all of them as the same error.

An application may answer a local health check while its public route fails. “The application returned HTTP 200 locally” is therefore not proof that the embedded preview works.

If Amazi reports an unhealthy application while the preview works, ask it to distinguish the current application check from its database check and earlier failed starts. A recovered application with an available database should no longer be reported as unhealthy because of the database status.

Recover without losing the work

1. Wait for any active preparation or deliberate restart to finish.
2. Use the visible Retry action and confirm the selected application and route.
3. If the failure persists, ask Amazi to inspect application startup, its configuration, the configured port, public routing, and the exact failing URL. Amazi can inspect available startup diagnostics itself; you do not need to find a server journal or paste passwords and keys into the chat.
4. If it cannot establish a safe fix, send the evidence through Troubleshooting and support.

Do not delete the project, reset its database, or repeatedly start new paid tasks simply to clear a preview error. Startup time depends on the work required; an indefinite “starting” state needs diagnosis, not an assumption that it is normal.

If several previously working projects stop opening at the same time, report them together to Support. Shared startup failures can require a platform fix; recreating each project or changing its dependencies is not a necessary first step.

When the first creation task fails or is stopped, the preparation screen ends. Any preview already available remains accessible; stopping the task does not finish missing parts of the application.

Embedded preview versus a separate tab

Preview is embedded in a cross-origin frame. Sign-in redirects, cookie behavior, and browser security restrictions can differ from opening the same address separately.

If the separate page works but the embedded view does not, report both results. Ask for the actual authentication or framing issue to be checked; removing security controls indiscriminately is not a reliable fix.

Why is the project card image old?

The card image is a captured screenshot, not the live application. New committed work is captured separately. If capture fails, the last successful image can remain while a later capture is retried.

Open Preview to inspect current behavior. Report a stale thumbnail separately from a broken runtime so a working app is not rebuilt unnecessarily.

Preview changes are not a production release

Source updates can appear in development before publication. To update the public production version, use Publishing and domains. Always identify which address you tested when reporting a result.