Troubleshooting

Deploying

The Deploy button does nothing and no form appears

Usually the extension is not running on that tab — reload the editor. If it still does nothing, check the extension is enabled and that you are signed in; the toolbar button opens the console, which is the quickest way to tell.

If Bubble has changed its editor markup, the gate can lose track of the button. That is fixed on the service with a selector override and a restart, with no extension release — so it is worth reporting rather than working around.

It says the app has not been added

An administrator has to add that Bubble app to your organization first. An app nobody has added belongs to nobody, and allowing the deploy would put a production change outside every record in this product.

My approval arrived, but the gate closed again

Approval opens the gate for one deploy and fifteen minutes. Raise the request again. The window is short on purpose: an approval that could be banked and spent later would be an approval of a change nobody looked at.

Sign-in fails

Sign-in is Google only. If your deployment restricts sign-up to named Workspace domains, a personal account will be refused — ask an administrator which domains are allowed.

Approvals and notifications

Nobody was notified

Check Settings → Notifications. Three things have to agree before anything is sent, and the screen names whichever one is missing. The most common cause is a Slack account whose email address differs from the person's Google one — which is exactly why both channels are worth turning on rather than one.

The approver is away and the deploy is stuck

It is not stuck. The named approver is routing, not permission: any owner, admin or approver can decide a request they did not raise. Ask another, or re-route it so the notifications follow.

I raised it and I am the only approver

Then nobody can approve it, and that is the control working rather than failing. Add a second person with an approving role. There is no override — the rule is enforced in the database, not only in the code.

The automated review never came back

Reviews are collected by a scheduled sweep, so they land minutes after the request rather than seconds. A review that fails leaves the request pending for its human approver — it never fails a deploy, and it is never reported as having found nothing.

Automated approval is on but nothing is ever auto-approved

Most often the app is set to BuildGate's reviewer with no branch comparison available, which means there is nothing for that agent to read and no review of it can ever come back clean. The Apps screen names the switch that is missing. Check too that the app's branch pair is right: a review that diffs the wrong two versions is reviewing a change nobody made.

Backups, exceptions and the record

A backup failed

The Git screen records every attempt and the reason names which side gave up. An export failure is almost always a lapsed Bubble editor session. A size failure is the app measured against this deployment's limits. The rest is BuildGate's own side, and worth reporting.

An exception I do not understand

Read the name first — see what the findings mean. The distinction that matters most is between unlogged_deploy (one person went around a gate that works) and gate_not_enforcing (the gate itself has stopped working), because only the second one is an emergency for everybody.

Something is rate limited

Limits are set far above what honest use reaches, including a whole office behind one address. A refusal is worth looking at rather than tuning away.

Still stuck

Email [email protected]. If it concerns a specific deploy, the request has its own address in the console — send that link.