Fix a publishing problem

You can use the message beside Publish or in its dialog to find out what's stopping your changes from going live. Start with the matching section below. A failed attempt doesn't necessarily lose your draft, and a successful publish can leave out features your plan doesn't support.

Publish is disabled or the changes bar is missing

1. Check that you've selected the right project.
2. Finish your edit and let the draft save.
3. Resolve any save error or reload-conflict notification.
4. Open the unpublished changes count to see what differs from the published setup.

For ordinary project users, Publish is disabled while the project configuration is saving or loading, when no project is available, or when there are no detected changes. An unrelated analytics report loading doesn't block publication by itself. If your draft matches the published setup, there's nothing new to publish.

The public demo cannot publish. Use your own project for a real release.

The dialog says to fix an issue before publishing

Open the resources named in the dialog and fix the listed issues before trying Publish again.

The validation dialog says Fix this issue to publish, or lists several issues. It also confirms that nothing has gone live and your changes are saved as a draft.

Enlarge

Publish validation explaining that forms need an email integration before the draft can go liveOriginalOriginal

A form needs an integration

Open Integrations and connect the email platform that should receive the form's data. A form whose action sends to an email platform needs a native connection. If you intend to send the data to a webhook instead, configure the form's webhook action. Your plan must support webhooks.

Follow the message's named forms. A draft-only, unused form isn't treated the same as a form used by a live path.

A form's action isn't fully configured

1. Open each named form.
2. Open its Actions tab.
3. Complete the required destination settings.
4. Let the draft save, then try Publish again.

Connecting the platform alone doesn't fill every form's required action settings.

A rule needs contact data from an integration

Connect the relevant integration, or remove the contact-status rule if you don't need it. Flows or segments that depend on whether a visitor is an anonymous or known contact require that integration.

Forcing a segment in the debugger only simulates a visitor. It doesn't fix the missing integration.

Bot-protection keys are invalid

Correct the project's Cloudflare Turnstile configuration, then retry. RightMessage checks the key format during publication. Keep the site key and secret key in their separate fields, and don't expose the secret in a support screenshot.

Two sync paths use the same custom field

Choose separate destination fields for the two values, then retry. A legacy choice question's Other freeform answer and its structured segment sync can't write to the same custom field.

Payment or subscription blocks publication

A failed payment can replace the normal publish action with Update payment to publish. Use that action to resolve payment through billing, then return to the project's publish review.

If the project's billing setup didn't finish when it was created, its 14-day trial hasn't started yet, so publishing asks you to choose a plan and start it. A project with incomplete trial activation opens a recovery step instead, which can show Publish changes for an existing trial.

If the app says Could not load billing plans, retry the review after the connection recovers. If it says Could not load billing recovery, retry publishing to resume activation. Neither message is a success confirmation.

For a billing-state conflict, let the app refresh the current activation state. Review that state rather than opening several checkout attempts. If the conflict persists, give support the project and exact message without card details.

Publication succeeds but a feature doesn't go live

Return to the publish review and check for Some features won't go live on your current plan. This warning allows the eligible configuration to publish while excluding locked features. It's different from a validation failure.

Campaigns and conversion goals require Scale or Pro. A draft can contain them even when the current plan can't publish them. If the omitted feature is required:

1. Return to the publish review and read the listed feature requirement.
2. Resolve the plan requirement through Upgrade.
3. Review the draft again.
4. Publish and check the intended page.

Check the campaign or goal itself. Another change going live doesn't mean an excluded feature went live too.

The project changed elsewhere

If a notification says your unsaved edits are still on screen:

1. Note or copy the unsaved text you need to keep.
2. Coordinate with the other editor so you aren't changing the same resource at the same time.
3. Reload to use the latest saved draft. Reloading replaces the unsaved edits on screen.
4. Reapply only the edits that still belong in the updated draft.
5. Review the complete changes list before publishing.

Another tab, collaborator, Righty, or connected AI assistant can change the same draft. RightMessage rejects a stale autosave rather than silently overwriting the newer draft.

Don't keep resubmitting an old tab's full draft. Use Project Backups if you need to inspect or restore a saved version.

A server or connection error appears

1. Record the exact message and approximate time.
2. Restore your connection if it's interrupted.
3. Reopen the project and inspect the current draft and Project Backups publish history.
4. If the changes remain unpublished, review them before retrying.
5. If a new Published entry exists, check your live site before assuming the request never completed.

The generic message Failed to publish changes. Please try again. doesn't identify a configuration problem. If it persists, send support the project, time, message, affected resource, and target page. Don't include integration credentials, debugger tokens, or payment details.

My changes are published, but the page still looks wrong

Reload the target page and follow the intended visitor path outside the debugger, without forced segments or test assignments. Include the natural trigger and identification step. If you're syncing contact data, check the dedicated test contact in your email platform too.

Use the debugger and testing controls to see why the visitor does or doesn't qualify for your rules. A draft resource test can still need its own Start test action.

When the publish has an entry in Project Backups and the ordinary visitor path works, you're done. If you need to undo the change, restore an earlier version to the draft, review it, and publish that recovery.