How to read build logs when publishing fails

When a TeleportHQ publish fails while your site is being built, the message starts with "The deployment failed while building on Vercel." It quotes the log lines that say what broke (From the build log:), names the cause when TeleportHQ recognises it (Likely cause:), and ends with "Open the Deployments tab → Build Logs for the full log." To read the whole log, open Publish → Deployments, click the ⋮ button on the failed deployment and choose Build Logs. The log opens under the row, scrolled to the first error.

Before you start#

• Your live site is safe. A failed build never replaces the version that is already live.
• Role. You need the Owner, Admin or Designer role.
• Not every failure has a log. If the publish stops before the progress bar reaches Building your site (for example at Generating the code), no deployment is created, so there is no build log. See Publishing failed: what should I do?.

Steps#

1. Open your project in the editor.
2. At the top right, click Publish.
3. In the Publish window, click Deployments on the left.
4. Find the failed deployment. It is usually the newest row, with the status Error.
5. Click the ⋮ button at the end of the row.
6. Click Build Logs. The Build Logs panel opens under the row.

7. Click Errors only to hide the normal lines and keep each error with the lines around it.
8. Click the red counter, for example 3 errors ↓, to jump to the next error.

How to read the Build Logs panel#

The TeleportHQ Build Logs panel has these parts:

1. The badge shows the result: Build succeeded, Build failed, Build canceled or Build in progress.
2. The counters show how many errors and warnings the build had, and how long it took. Click the red error counter to jump from one error to the next.
3. Errors only keeps only the errors and the lines around them. It appears only when the log has errors.
4. The copy button copies the whole log, so you can paste it into a message to support.

Close hides the panel. In the log, error lines are highlighted in red.

How to use what you read:

• Start with the first error. Later errors are often caused by it.
• Warnings don't stop the build. You can usually ignore them.
• The counters go by words. Any line that contains a word such as "error" or "failed" counts as an error, so a build that succeeded can still show a few.

What to do next#

1. Look at the first error. It often names a page, a component or a file. If the publish message named a Likely cause:, start there: for example, "An element carries a custom "style" attribute with text in it. Remove that attribute and use the Style panel instead."
2. Undo or fix your most recent change to that part of the project, for example custom code you added.
3. Click Publish to Production again.
4. If the build fails again and you can't tell why, copy the log and send it to TeleportHQ support from the chat in the app, or by email to hello@teleporthq.io. You can also give support access to the project: see How to share your project with TeleportHQ support.

Troubleshooting#

"No logs are available for this deployment." The build didn't produce a log, for example because it was canceled early. Publish again.

There is no Errors only button The log has no lines that look like errors. Read the end of the log, or the error message shown when the publish failed.

"An error occurred while fetching Vercel logs. Please try again." TeleportHQ couldn't load the log. Click ⋮ → Build Logs again.

"The deployment was canceled before it finished building. Please publish again." Click Publish to Production again.

"Your project built successfully but its address could not be pointed at the new deployment. Please publish again." The build worked, but the address wasn't updated. Publish again. You don't need to read the logs.

"Error occurred while publishing" with a Publish without private files button Your project has files in the Private folder, and the publish failed. Click Publish without private files to publish the site without them. The status then says Published (without private files).

Good to know#

• Messages that block publishing before any build starts, such as too many forms or missing language slots, don't create a deployment or a log. See Publishing failed: what should I do?.
• To put a working version back online while you investigate, see How to go back to an earlier version of your live site.