Publish errors and troubleshooting

Where to find it

  1. Open your project.
  2. Click View logs at the top of any project page. Project Logs opens.
  3. Choose Errors or Warnings from the filter to narrow the list, or type in Search logs... to find a page by its URL.

Project Logs shows the most recent publish. The filter has All, Errors, Warnings, Success, and Info.

You can also get there from the Dashboard. The Rendering card shows a count such as "3 errors ยท 1 warning" after a publish. Click the count to open Project Logs already filtered to errors or warnings.

When a staging publish finishes with errors, WCH shows "There were 3 errors. Please verify the build or republish." A publish with no errors shows "Publishing to staging completed". Notifications in the project sidebar keeps a history of finished publishes and deploys, with who ran them and when.

How to read a publish

A publish has three places where it can go wrong:

  • Before it starts: WCH refuses the request and shows a message straight away. Nothing is rendered.
  • While pages render: WCH keeps going when a single page fails. Each problem page gets its own line in Project Logs. The rest of the site still publishes.
  • During a deploy: WCH built the site but could not deliver it to a destination. Your staging site is up to date. Fix the cause and deploy again.

Messages when you click Publish

These appear as soon as you click, and nothing is published.

  • Project is currently publishing.: another publish of this project is still running, started by you, a teammate, or a webhook. Only one publish runs at a time per project. Wait for it to finish, then publish again.
  • A production deployment is in progress. Wait for it to finish before publishing to staging.: a deploy is still sending your build to a destination. A staging publish would change the files mid-upload, so WCH waits. Publish again once the deploy finishes.
  • Connect to Webflow: the project's Publishing mode is API, which reads your pages through the Webflow API, and WCH has no Webflow connection for it. Click Connect and approve access in the Webflow window. The publish starts once you are connected. Click Cancel to stop.
  • Link a Webflow site: the Publishing mode is API, but the project is not linked to a Webflow site. WCH links the project from its source, so check on the Sources page that the source is your site's .webflow.io address. To publish in the meantime, set Publishing mode to Sitemap in Settings. See Publishing modes.

Messages that stop the publish at the start

Before rendering, WCH loads your source's homepage once. If that fails, WCH stops the whole publish and writes one of these lines.

  • Publishing failed: site is password protected and no password is configured.: your Webflow site has password protection. Go to Sources, open the menu on your source, and click Edit source. Tick Has password, enter the Site Password, and save.
  • Publishing failed: site password is incorrect.: the Site Password saved on the source does not match the one in Webflow. Update it with Edit source.
  • Publishing failed: could not authenticate with site password.: WCH could not complete the Webflow password sign-in. Check the Site Password, confirm the site opens in a private browser window with that password, and publish again.
  • Publishing failed: site is redirecting: the homepage did not load. It kept redirecting, or it refused the request. Open the source's homepage URL in a private browser window. Fix any redirect loop in Webflow, and make sure the source is the address your site is published to.
  • Publishing failed: cannot reach site: WCH could not connect to the homepage at all. Check that the site is published in Webflow and that the homepage URL on the source is spelled correctly.

Messages about single pages

These are per page. The rest of the site still publishes.

  • Page not found (404), removing pages for: the page now returns 404. WCH removes it from your staging build. This is expected when you delete or unpublish a page in Webflow. Your site's own 404 page is not affected.
  • Page permanently redirected (301), removing pages for: the page now redirects permanently, with a 301 or 308. WCH removes it from your staging build, the same as a deleted page. WCH does not publish the redirect. Configure it at your host. See 301 Redirects.
  • Failed to fetch followed by Upstream redirected (HTTP 302), or 303 or 307: the page redirects temporarily. WCH does not publish the page it redirects to, and it does not remove the page either. The copy from the last successful publish stays in the build. If the redirect is intended to be permanent, change it to a 301 in Webflow. Otherwise remove the redirect and publish the page again.
  • Failed to fetch followed by Upstream returned HTTP and a status code: Webflow answered with an error for that page. This is usually temporary. Publish the page again from the Rendering page. If it keeps failing, open the page in a private browser window to see the error.
  • Failed to fetch followed by Cannot get information from this link: WCH could not connect to that page. Publish it again. If it keeps failing, check the URL in Webflow.
  • Site has password.: the page asked for a password during rendering. Add the Site Password to the source with Edit source, then publish again.
  • Page no longer exists in Webflow: in API Publishing mode, WCH found a page in your build that is no longer on your Webflow site, and removed it from the staging build.

To publish only the pages that failed, open Rendering, select them, and click Publish selected. See Rendering.

Pages that WCH removes from the staging build are not removed from your destinations. No destination deletes files. Remove them at your host. For S3, see Removing Dead Files During an S3 Publish.

Messages during a deploy

These appear after you click Publish or Promote on a destination. Your staging site is not affected.

  • Something went wrong when creating the archive: the build had too little in it to deploy. Usually the staging build is empty or a staging publish did not finish. Run Publish all pages, check your staging site, and deploy again.
  • Deployment aborted followed by stylesheet(s) in the build are not valid CSS: WCH checks the stylesheets when it builds a new archive for an S3, Aliyun OSS, or SFTP destination. If one is not a real stylesheet, WCH stops the deploy so your live site is not left unstyled. Run Publish all pages, then deploy again.
  • Deploying to S3 Failed with error: WCH could not upload to your bucket. The rest of the line says why. See the troubleshooting sections of AWS S3 Authentication and AWS Production Deployment.
  • Azure token expired. Please re-authenticate with Azure. or No Azure Token.: the Microsoft sign-in for an SSO destination has lapsed. Open Extensions, then Deployments, click Update Configuration on the Azure destination, and click Reconnect with Azure. See Azure: Basic Implementation.
  • Deploying to Aliyun OSS Failed with error: see Aliyun OSS: Basic Implementation.
  • Deploying via SFTP failed., Failed to upload files over SFTP., or SFTP hosting is not properly setup.: WCH could not sign in to your server or write to the folder. Open Extensions, then Deployments, click Update Configuration on the SFTP destination, and check Host, Port, Username, both keys, and Folder. Confirm the public key is authorized for that user on your server.
  • Github is not connected for this project. or Failed to push to Github: WCH has no working link to your repository. On the Deployments page, reconnect GitHub or link the repository again. See GitHub: Basic Implementation.

Publishes started by webhooks

  • Skipped while busy. If a Webflow publish or a CMS change arrives while WCH is already publishing the project, WCH skips it and does not queue it for later. Publish again from the Dashboard once the current publish finishes. See Webhooks.
  • Publishing mode is API but no Webflow token for this site: a webhook started a publish for an API-mode project that has no Webflow connection. WCH published from your sitemap instead. Publish once from the Dashboard and click Connect when WCH asks, so later webhook publishes use the Webflow API again.

An internal error occurred

Some failures show "An internal error occurred" and say the details were recorded for support. The cause is on WCH's side, not in your settings. Publish again. If it happens again, contact WCH support with the project name and the time of the publish.

Testing your fix

  1. Change the setting or fix the page in Webflow, and publish in Webflow if the fix was there.
  2. In WCH, publish only the affected pages from Rendering with Publish selected, or run Publish all pages.
  3. Open View logs and filter to Errors and Warnings. Confirm the message is gone.
  4. Check the page on your staging site.
  5. Deploy to your destinations again.