---
title: "Form failed to publish"
description: "Fix the schema, upload-storage, response-limit, and code-sync problems that block a publish."
group: "Reference"
order: 9
type: "troubleshooting"
parent: "troubleshooting"
keywords:
  - "publish failed"
  - "schema validation"
  - "file storage"
  - "code sync"
updated: "2026-07-14"
---

Publishing validates the whole draft, not just the field you last edited. Read the publish error, keep the draft open, and fix what it names before trying again.

## Common blockers

### Invalid schema

Every page, field, option, and logic target needs a stable unique ID. Required properties vary by field kind. Conditional rules, page jumps, answer piping, response limits, and completion settings must reference IDs that still exist.

If you removed or renamed a field, search the entire schema for its old ID. A field can look fine in the visual builder while a jump or limit still points at the deleted value.

### Upload storage is unavailable

A form containing `file_upload` needs a usable storage configuration. Connect Google Drive, Box, or S3, repair any unreadable provider credentials, and publish again. Fillo doesn't proxy provider uploads as a fallback.

### Response-limit configuration is unsafe

A field-based identity has to point at a suitable always-visible, required email or phone field. A scope field has to be scalar, and visible when required. Update in place needs person identity — browser or self-claimed contact matching won't do.

### Code-defined form limits

Keep the schema within the workspace's code-defined form count and payload-size limits, and use stable handles and field IDs. An authenticated push or an allowed publishable-key sync stages a changed schema in a claimed workspace — it doesn't make the change live. Open the dashboard, review the staged draft, and publish it.

With an authenticated-only sync policy, browser code can't stage changes. Use `fillo push --stage` or a server sync token rather than weakening the policy to get a deployment through.

## Verify the live version

After publishing, open the hosted form in a fresh session and confirm its version and behavior — existing visitors can still be on an older page session. Send one test response, then check the response grid and enabled destinations.

## Related

- [Authoring forms](/docs/authoring): Understand draft, staged, and published form states.
- [Schema reference](/docs/schema): Validate field, page, logic, and settings structure.
- [File uploads](/docs/uploads): Connect storage before publishing upload fields.