Build previews use hostnames like this: https://build-12345678-9abc-def0-1234-56789abcdef0.gtsb.io/ https://siteprefix-branchname.gtsb.io/ These would be better: https://build-12345678-9abc-def0-1234-56789abcdef0.siteprefix.gtsb.io/ https://branchname.siteprefix.gtsb.io/ The use case here is whitelisting OAuth domains. I can't safely whitelist all Gatsby build domains. With the prefix as the third-level domain, I could safely whitelist *. siteprefix.gtsb.io for authentication operations.

Add A/B testing by branches like Netlify

We currently do not have the option to change the payload that Gatsby sends for outgoing webhooks, because of that, we are unable to make it work with Microsoft Teams. I have confirmed that with Gatsby Support, ticket #25213, and they suggested that i posted here as a feature request.

Having the web UI as the sole interface for configuring a large number of sites is just painful. Headless Gatsby Cloud, no ?

Outgoing notifications when a new preview build is done should contain the Git commit hash that generated this preview. This enables us to easily link which preview URL's correspond to which builds in our CI pipeline.

Currently all build links in the Cloud UI point to the root of a site, ideally Cloud would allow you to set the 'start' page or path for those URLs should there be no page at the root. For example if a site is in multiple languages the 'homepage' might actually be at /en

Would be nice to have the ability to select a tag instead of a branch in the site settings. It would be very useful to perform temporary "code rollback" meanwhile the dev team work on a fix.

Currently subsequent builds often start the deployment from scratch, without using a cache from a previous build. For example you had deployment on Friday, then on Monday you trigger a new build from any source and it most likely will start installing dependency from scratch and pull all the data from the CMS, like there is no cache at all. Happens on Gatsby Cloud all the time in every project we have.

SSG counter is very confusing at this moment and looks more like a bug without an additional explanation. It either should show the number of SSG pages or completely rephrased if there is a need to show the number of all assets generated on the site.

Currently lighthouse reports are generated only for the home (/) page. It would be useful to have this configurable. Example use case: all of our regional gatsby sites have the'/' redirected to /xx/ page (replace xx with regional ID). Due to this, lighthouse reports are not generated in gatsby cloud.