1Footer documentation
What automatic maintenance handles
Understand which website changes trigger checks, what a supported repair preserves, and when a connection needs your attention.
Last reviewed
1Footer owns the maintenance loop
For supported connected delivery, 1Footer runs scheduled checks and coordinates repairs in the cloud. Your host, source provider or CMS executes the authorized publishing actions. You do not need a local runner or an open browser.
Automatic repair is specific to the current delivery adapter. The support matrix distinguishes released automation, packages you install yourself and native adapters still in development. A working export does not mean every future migration can be repaired automatically.
Changes that need a fresh delivery check
| What changed | What 1Footer checks | What the repair needs |
|---|---|---|
| Hosting or framework | Fresh public host and framework evidence, plus the current footer output. | A released adapter and authorized access to the destination. Old builder markers alone cannot select the host. |
| Project or source repository | The project serving this domain and its matching source access. | A verified site/project binding. Access to the previous project cannot authorize an unrelated replacement. |
| Footer publication | The actual public links against the current published footer for this website. | A supported managed delivery path, or a new build/CMS publication for static snapshots. |
| Page rules or paused delivery | Whether the current route should receive the footer at all. | The saved rules and pause state. Maintenance must not resume an intentionally paused footer. |
| Theme or native installation | Whether the active native delivery is present and still matches the publication. | The platform-specific native adapter. Broader native recovery is in development; see the platform matrix. |
| Public domain or publishing account | Ownership and the website binding for the new destination. | A verified updated connection. Automatic domain/account reassignment is not released across every platform. |
Keep your settings and unrelated changes
A supported repair stays within its owned installation. An edited or unrecognized integration can need attention so that customer changes are preserved. Removing an arbitrary footer or unrelated navigation is not a valid repair.
- Your published content: Repairs use the footer you published for that website. A saved draft stays a draft.
- Your page rules and pauses: An intentional pause stays in place. Included and excluded pages keep their own delivery rules.
- Your connected accounts: Changes stay within the website and publishing account you connected. A new host needs its own authorized connection.
- Your existing website: Supported repairs check for conflicting changes and reconcile uncertain writes before retrying. Failed deployment checks can restore the previous deployment.
Recover without duplicating uncertain work
A provider can accept a publishing operation even when its response is lost. Supported repair workflows retain progress and reconcile that outcome before another write. A timeout alone is not permission to start a second deployment.
Verification must compare the public result with the publication and website state being checked. A failed supported deployment repair can restore the previous deployment. Access changes, conflicting edits and provider outages can prevent completion; a pending repair is not a verified footer.
AI assists inspection; public output proves delivery
1Footer uses its existing Vercel AI SDK integration for AI-assisted project inspection where useful. Provider actions stay constrained by the connected website, permissions and supported repair tools. Routine adapter checks do not need an AI-generated publishing command.
An AI response, successful connection or completed build does not prove delivery. The public page must contain the expected footer. Initial HTML, page targeting, navigation and pause/resume behavior need their own checks.