A failed build.A useful next action.

Start with the release, not a new retry.

A deployment can fail before your build tools run, during dependency installation, while compiling the app, or during publication. An application can also publish successfully and then fail on a request. Those are different failure classes. Repeating the same deploy without identifying the stage often only adds another identical entry to history.

Open the project’s Deployments workspace and select the relevant release. The release panel keeps Source, Build, Publish, the originating commit and output together. Follow build from Overview opens that same release. Confirm you are investigating the intended commit before editing code.

If an earlier release was live, it keeps serving while a replacement build fails. If this was the first deployment, there is no older app to fall back to. That distinction tells you whether the immediate task is restoring customer traffic or finishing an initial setup.

Source acceptance: inspect the archive or commit.

For an archive, check that it contains the intended project root. A plain site needs index.html at the root; a source application needs the correct package.json and lockfile. A ZIP nested inside an unexpected parent folder can describe a different project than the one you meant to ship.

Fortly checks compressed size, expanded size and file count. The documented ceilings are 256 MB compressed, 2 GB after unpacking and 50,000 files. Path traversal, links and unsupported archive entries are also rejected. A refused upload is not fixed by changing an application route.

For GitHub, check the linked repository, branch and commit. If deploy-on-push did not start, review webhook setup and repository permissions. If another build is already active, Fortly allows only one build at a time per project; wait for it to finish instead of starting a competing release.

Builder connection: distinguish platform availability.

Build service unavailable means the platform could not reach its build service. Your source may have arrived, but the installer or compiler did not complete. An edit to the application’s JSX or SQL cannot repair that connection.

Retry once after checking the current status. If the diagnostic repeats, keep the release and its timing for the Fortly team. A build storage failure is another platform-side resource problem: the builder must reclaim space before an install can proceed. It should not be treated as a reason to regenerate a dependency lockfile.

Release output may temporarily lose its connection while the build itself continues. Use the reconnect control and the last known state. Returning to the page refreshes status. A disconnected log stream is not, by itself, evidence that a build has stopped.

Dependency installation: read the actual command.

Check which package manager and version the project declared, which lockfile was selected and which install command failed. Keep one intended dependency history. The packageManager field takes precedence over incidental extra lockfiles; the build output records the manager used.

A frozen install can fail because the manifest and lockfile disagree. Fortly can retry dependency resolution in its disposable workspace and tells you when it does so. That fallback is narrow: it is not a retry for a failing install script, a storage failure or a network error. Use the first meaningful package error rather than only the final exit code.

Public HTTP/HTTPS downloads for build-time assets are supported through a controlled proxy. Private or reserved destinations and unsupported ports remain blocked. If a custom dependency client ignores proxy configuration, configure it correctly rather than assuming the build has unrestricted network access.

When the problem reproduces locally, repair the dependency graph or install script and commit the intended lockfile change. If it occurs only in the deployment environment, compare the declared package manager, required build values and the actual diagnostic before replacing dependencies at random.

Application build: check the runtime contract.

A successful install only proves dependencies were installed. Read the first compilation, type-checking or output-packaging failure. Missing build values, the wrong project directory, an unsupported adapter and a native runtime assumption produce different remedies.

• For a static site, confirm the generated output contains index.html in a recognized directory.
• For Next.js, decide whether the app uses a server build or output: "export" and inspect the matching output path.
• For an HTTP server, make the JavaScript entry point clear and use the documented server adapter requirements.
• For provider-specific services, migrate the backend deliberately. A frontend build cannot provision missing Cloudflare bindings or Pages Functions.

Fortly’s server-framework builds produce Workers. Skipping that build and uploading an unadapted server package does not create a runnable application. Use the supported source path and the framework compatibility reference to check the specific requirement.

Publication: build completion is not the live state.

After a build, Fortly uploads and validates its artifact before making the release live. The build output can say complete while publication is still running. Use the release state to decide whether visitors are reaching the new application.

If validation fails, read that diagnostic rather than changing unrelated source. The previous live release remains the useful recovery reference. Keep the failing release ID, source commit and original output for a support request; these tell the team which artifact was being checked.

A live app: inspect a real request.

Once the release is live, move from build output to Observability → Logs → Runtime. Worker logs arrive after requests finish, including bounded background work. Test the same route, caller and data operation that failed in the browser.

A 403 from the Data API can mean the selected role lacks an applied grant; rebuilding the frontend does not apply that grant. A missing NEXT_PUBLIC_ value may have been compiled incorrectly and require a new build. For a Worker database failure, check that the project database is provisioned, the driver supports the Worker runtime, and connections open inside the request. The database connection guide covers the supported setup. Identify which contract is wrong before deciding whether the fix belongs in code, configuration or access controls.

Download logs you need to retain and keep a short incident record: release, commit, failing request, first meaningful error and the action that resolved it. If you review a rollback, remember that it restores the application release, not database contents, files or environment values.