When your site will not go live

It says something went wrong and nothing else

You press Put it online, it thinks about it, and then: something went wrong at our end, try again in a moment. Trying again gives the same sentence. There is nothing in it to act on and no clue which part failed.

This is our fault rather than yours, and it is worth knowing exactly what happened. The publishing code writes a real reason every time — that the token was refused, that the hosting account is paused, that a site of that name is already mid-publish, that the build itself failed and the reason the hosting account gave for it. Those sentences were written to be read by you. On the way out to your screen they are all replaced by the one fixed apology. The real one is kept on our side, so if you write to us we can read it back.

Two things it does not mean. It does not mean your site is broken, and it does not mean the build has been lost. A publish either completes or nothing happens at all.

1. Make a fresh access token and paste it whole. A token copied in two halves, or one that has quietly reached its expiry date, is the single most common cause.
2. Check the token belongs to your own account rather than to a company or a team. That one has its own trap and its own section below.
3. Check the hosting account the token belongs to — Vercel, if you followed the guide under the token box — is not paused. A spending limit, or a month that has run out of build minutes, stops a publish dead and looks identical to everything else from where you are sitting.
4. Open the Code pane and look for the file that starts the site, described further down. A site that cannot be built fails at the far end, minutes in, and this is the usual reason.
5. If none of those is it, write to us from the contact page and say roughly when you tried. The reason is in our log with the time on it.

Tip. Nothing has been lost while you work this out. A publish that fails leaves the project exactly as it was, every earlier version is still there, and the free grafter.build address goes on working the whole time.

Note. A publish holds the page open while it waits, for up to about three minutes. If it has been longer than that, it has genuinely failed rather than being slow.

The token from a company or a team account

If your hosting sits under a company or a team rather than under your own name, publishing will be refused however many new tokens you make. The refusal is real and your tokens are fine. Grafter only ever publishes to your personal account, and there is nowhere in the form to tell it about a team — so a token scoped to a team is being used against a scope it does not cover, and the answer comes back as no permission.

That is a gap rather than a hiding place. Here is what works today.

1. On the hosting site, check the box at the top left of the page is showing your own name and not the company's.
2. Make the token with its scope set to your own account. The option is usually called Full Account. A token tied to a team, or to one existing project, cannot create the new project a publish needs.
3. Publish. The site lands on your personal account.
4. If it has to live under the company in the end, move the project across from the hosting account's own settings afterwards. That is a move it can do and we cannot.

Note. The folded guide under the token box says this in its first and fifth steps. It is worth opening once even if you have made tokens before, because this is the step people who know what they are doing skip.

It looks finished, and the build fails

A site can look complete in the Preview pane, and on the free address you have already sent to somebody, and still fail the moment it is built for real. The downloaded zip fails the same way: every file is there and nothing starts.

The cause is almost always one missing file — the small one that starts the site and puts everything else on the screen. A first build that ran out of time very often has not reached it, because the builder writes the design and then the sections and leaves the thing that mounts them until last.

The preview covers for that, and that is why it stays hidden. It looks at what is there, works out what was probably meant, mounts the site anyway and shows you something finished. Nothing that builds for real is that forgiving. So the gap is invisible until the one moment it costs you.

1. Open the Code pane and look down the file list for src/main.jsx.
2. If it is not there, ask for one more turn in your own words: add src/main.jsx that mounts App and imports the stylesheet.
3. Let that turn finish, then publish again.

Tip. No src/main.jsx in the file list means the export will not build, however good the preview looks. It is the one check worth making before every first publish.

Note. On a desktop screen the preview shows a small note count above the site when it has had to fill that gap in, and the note behind it says so in as many words. It is easy to miss, which is why the file list is the check to trust.

You closed the panel and the address went with it

The address arrives as a line under the button, reading Live site and then the link. Close the menu and that line is gone. It is not written down anywhere — nothing on your account records where a site was published to — so there is no screen to go back to and no history to dig it out of.

Do not publish again. The site is almost certainly live, and publishing again is exactly how people end up with two of them.

1. Sign in to the hosting account you published to — vercel.com — and open Projects. Your site is there, under whatever was in the Name for your site box.
2. Its address is that name followed by .vercel.app. Keep that one — the next section explains why it is a better address than the link we showed you.
3. For a copy saved to GitHub it is the same shape of answer: the repository is under your own account, named as the Name for the folder box had it.

Why the tab has to stay open

A publish can take up to about three minutes and the page waits for it. Closing the tab, or moving to another screen while it runs, stops us watching. It does not stop the build: once your files have gone over, the hosting account finishes the job on its own and puts the site up without us.

So a publish you walked away from may well have worked. Check the hosting account before you try it again.

Note. The token is not kept either, which is why the form asks for it again next time. It goes over for the one job and is dropped when that job ends — nothing writes it to your account or into this browser.

The link you gave out still shows the old site

You published, sent the address to customers, changed the phone number, published again — and the link everybody has still shows the old version. Sometimes there is now a second address as well.

Nothing is stuck and nothing is cached. There are two separate causes here and they need different answers.

The long address is a snapshot

Every publish creates its own permanent address, the one with a run of random letters in the middle of it. That address is frozen. It shows the build it was made from and it will show that build for good, which is genuinely useful for going back and looking at an old version and exactly wrong for handing to a customer.

The address that moves is the short one: your site's name, then .vercel.app. That is the one every publish updates and the one to put on the van.

The link we show you after a publish is the long one. That is our fault, and until it is fixed the short address has to be read off the hosting account's own page.

1. Open Projects on your hosting account and press your site.
2. Take the short address at the top of that page — the name, then .vercel.app.
3. Send that one to anybody who is already holding the long link.

A changed name makes a second site

The other cause is the Name for your site box. Whatever is in it decides the address, and the hosting account finds an existing site by matching that name. Change it — tidy it up, drop a word, add the town — and the next publish makes a second, separate site at a second address. The first one is not touched. It carries on serving the old build to everybody who has its link.

The box does warn that the address cannot be changed afterwards, and that is true. What it does not say is what happens if you change the box instead, which is this.

The name is not used quite as you type it. Anything that is not a letter or a number becomes a hyphen, and hyphens at the ends are dropped, so Flow Plumbing Ltd. and Flow Plumbing Ltd are the same name while an apostrophe in the middle makes a different one. The box arrives already written the way the address will read; type over it and that translation still happens, out of sight.

1. Leave the name exactly as it was on the first publish. Every time.
2. If you already have two, the tidying up happens on the hosting account rather than here: delete the one holding the stale site, or point your own name at the right one.
3. Give the surviving address to anyone holding the other link. Nothing in Grafter can merge two sites or move an address between them.

Tip. For a genuinely different second site, make the name clearly different rather than nearly the same. Two names that come out identical after that tidying up will land the second site on the first one's address — and a copy saved to GitHub under a name already in use replaces what was in it, so a second project can overwrite the first project's files.

A Built with grafter.build badge has appeared

The badge in the corner of a shared site is worked out at the moment somebody opens the page, from the plan on the account right then. It is not baked into the link when the link is made. So it can appear on an address that has been in circulation for weeks, on every site on the account at once, with nothing having been published, edited or touched.

The usual reason is the plan: a card that failed, a subscription that lapsed, or a move to a tier that carries the mark. Restarting the plan takes it off again and a refresh of the page is enough to see that.

There is a second reason and it is ours. When we cannot read which plan an account is on, we show the badge rather than risk leaving a free site unmarked. A single failed read of your account therefore looks precisely like a billing problem. If your plan is definitely current and the badge is still there, that is what has happened, and it needs fixing at our end rather than yours — write to us and say which site.

Note. The badge only ever appears on the free grafter.build address, because it is drawn by the page that serves that link. A site published to hosting of your own has none of that around it, so the version your customers see there cannot change under you whatever happens to the plan.

Putting your own name on it

There is no domain setting in Grafter. No box to type mickplumbing.co.uk into, no screen for it, nothing waiting to be found once you look hard enough. If you started a plan because the message at the moment of publishing said it would give your site a domain, that sentence is wrong and the correction is ours to make: what a plan buys is the two ways out — publishing to hosting of your own, and taking the code with you.

Getting a name of your own takes four steps, and only one of them happens in Grafter. None of it is difficult, and the name itself is usually under £20 a year.

1. Buy the name at a registrar. Around £8 to £15 a year for a .co.uk, a little more for a .com.
2. Publish the site to your own hosting account first, so there is something for the name to point at.
3. On the hosting account, open the project, then Settings, then Domains, and add the name you bought.
4. Paste the two or three records it hands back into the registrar's DNS page. It usually works within the hour, though it can take a day to reach everybody.

Tip. Do this before you hand the address out rather than after. A name stays yours for as long as you keep renewing it, and the .vercel.app address behind it can then change without anybody having to be told.

Note. There is a separate guide to choosing the name itself — what to put in it, what to leave out, and which ending to buy.

Common questions

Does publishing take my site off the free address?

No. The free grafter.build address goes on working exactly as it did, and both stay live. Publishing puts a copy on hosting of your own; it does not move anything.

Why do I have to paste the token every time?

Because it is never kept. It goes over for the one job and is dropped when that job finishes — not onto your account, not into this browser. Pasting it again is the price of it not sitting anywhere.

Can Grafter publish into my company's team account?

Not today. Make the token on your own account, publish there, then move the project across from your hosting account's own settings.

I published twice and now I have two sites. Can they be merged?

No, and the hosting account cannot merge them either. Delete the one holding the old build, or point your own name at the one you want, then give that address to anybody holding the other link.

Why does the build fail when the preview looks perfect?

The preview fills in the file that starts the site when the builder has not written it yet. A real build cannot. Check the Code list for src/main.jsx before you publish, and ask for it in one more turn if it is missing.