When publishing fails
Publishing runs on your own Supabase, GitHub and Netlify accounts, so most failures are decided there. Each named cause and its gesture.
Fix a problem
Publishing creates three things on your own accounts: a Supabase database, a private GitHub repository, and two Netlify sites.
Because those accounts are yours, most of the time publishing fails for a reason that lives there. The Publish button says everything in a notification at the bottom of the screen. It opens no window.
It is refused before it starts
- Free plan. Publishing requires Pro or Max, and the refusal is immediate.
- A service is missing. The notice names the service to connect, and nothing leaves.
Updating an existing site is different: it costs no credits, on any plan, and an editor can run it.
The four causes a retry cannot fix
Each one lives in your Supabase account. MaShop names it and hides the Try again button, because pressing it would change nothing.
| What you read | What to do |
|---|---|
| Supabase project limit reached | The free Supabase plan allows two active projects. Pause or delete one on supabase.com, or move that account to a higher plan. |
| Unpaid Supabase invoice | Open the Invoices page of your Supabase organization and settle it. |
| No Supabase organization | Create an organization on supabase.com. Every project belongs to one. |
| Supabase connection expired | Reconnect Supabase in Settings, then Connected services. |
A recorded failure keeps being opposed for 30 minutes. If you fixed the cause and the same refusal returns, publish again after that delay.
The causes a retry does fix
Storage not initialized, Database not prepared, GitHub side problem, Deployment stopped, Publishing stopped. Press the button again.
The run saves its state and resumes at the stage where it stopped. Nothing that already passed is redone, and the 30 migrations already applied are never replayed. Publishing walks through the whole sequence.
It takes longer than expected
The browser relaunches the operation up to 120 times, three seconds apart. After that the notice says it is taking longer than expected, while the work continues on the server. Reload the page, then press the button again.
Two known defects live here. Nothing tells the workspace that a first publish succeeded, so the button stays on Publish and the address stays hidden until you reload the page. And the step counter can read 30 of 12, because its total is frozen at twelve while thirty migrations are applied.
The update runs but the site does not change
- The update failed. Your live site has not changed. Open View logs. The build runs on your Netlify account and reads your GitHub repository.
- Daily limit of 3 deployments reached. Read the number, not the word: the Free plan allows three, and the counter clears 30 days after the first one, not the next day. Pro and Max are unlimited.
- Your manual edits are not in the build. Saving in the editor writes to MaShop only. Nothing reaches GitHub from there, and the build reads GitHub. Ask the assistant for the change instead, so a generation commits it.
- You restored a version. Restoring replaces the workspace files and can write a commit, but never refreshes the live site. Press Update afterwards.
Restoring never touches your database. Snapshots hold code files only, so whatever your database already holds stays exactly as it is.
Never delete the project to unblock a publish
Deleting destroys your GitHub repository, using your own token. Without a local clone, nothing is recoverable. It also leaves your Supabase database in place, whatever the confirmation screen lists.