Troubleshooting and support

Normal, and usually a one-line fix. Tell the agent specifically what is off, and attach a screenshot; it fixes what it can see far more reliably than what it has to guess at. Short, specific feedback beats re-explaining everything. See the prompting guide.

Point it out concretely: "you also changed the header color, put it back". For the whole change, the Undo button on the agent's message restores every touched file at no token cost. To prevent it, scope your requests: "on the Contact page only, ..." keeps edits contained.

First check you are looking at the right place: the preview tab (not the published site), and the right page inside the app. Then give the rebuild a few seconds. If it is genuinely absent, say so: "I do not see the new button on the Services page", and the agent will re-check its own work.

One project runs one AI change at a time. If a change is still in flight (including an automatic repair), a new message can be refused until it finishes. Wait for the working indicator to settle and send again. If a turn has been spinning for many minutes, reload the page; an interrupted turn releases its lock shortly.

The composer accepts images and common document types, up to 4 attachments per message and 8 MB each. Convert exotic formats (a HEIC photo, for instance) to PNG or JPG and re-attach.

If the agent describes platform behavior that contradicts these docs, trust the docs and rephrase your request around what actually exists. See Known limitations for the honest map.

Plan mode is a paid feature. On the free plan it shows with a lock; upgrading to Starter or above unlocks it. See Plans and pricing.

Three exits, in escalating order: Undo on the agent's last message, asking the agent to revert in your own words, or rolling back the live app to a previous published version. All three are covered in one page.

Vaulter repairs most build problems automatically behind the loading cover; this message means the automatic attempts ran out. Try Retry first. If it persists, tell the agent what you were doing when it broke; it can read the build logs directly. See Auto-fix and build repair.

A blank render triggers its own automatic repair once per build, so wait a moment first. If it stays blank, reload the preview, then tell the agent "the preview renders a blank screen" and mention the last change you made.

The preview rebuilds after every change but the browser can hold a stale frame. Reload the preview panel. If reloading does not help, make any small change (or ask the agent to rebuild) to force a fresh build.

Runtime errors in the preview are caught and sent to the agent as targeted fix requests automatically, with attempts spaced out so they never spiral. If the error keeps returning after a repair, describe the exact click path that triggers it; the reproduction is the diagnosis.

Apps with sign-in enabled show their real auth in the preview too. Create a test account, or sign in with one you made earlier; testing as a real user is the point. Two test accounts is the recommended setup for verifying data privacy.

Uploads are capped by plan: 10 MB on Free, 50 MB on Starter, 100 MB on Pro and Teams. Oversized files are refused. If a common file type (a CSV, for instance) is refused as unsupported, tell the agent; the allowed types are configurable per app.

The change is in your preview but not published. Visitors see the last published version, always. Hit Publish. The one exception: auth settings (providers, who can sign in) reach the live app immediately without a republish.

Publishing is counted per workspace over a rolling 24 hours: 10 per day on Free, 50 on Starter, 200 on Pro, unlimited on Teams. Wait for the window to roll, or upgrade. Failed builds and rollbacks do not count against the limit.

Publishing validates your app before it ships, and refuses rather than shipping something broken; the message says which check refused. A failing database migration is the most common blocker (see the Data section below). Fix the named problem, then publish again; the failed attempt did not consume your daily count.

Almost always a version gap: the live app is an older publish. Publish your current state. If the error is genuinely live-only, roll back to the last good version first (Vault → Deployments), then debug in the preview without your users watching.

On the free plan, published apps are deliberately kept out of search engines. On paid plans, indexing is on and Google auto-indexing submits your sitemap for you, but Google itself can take days, especially for a brand-new domain.

The cleanest lever is require sign-in to view: the app stays published, but nobody outside your invite list can see anything, effective immediately. Deleting the project takes the app down entirely. If you need an app fully unpublished but the project kept, contact support.

Check your access setting in Vault → Auth: with "Only people on your list", anyone not invited is turned away with "You do not have access to this app yet. Ask whoever runs it to send you an invite." Add them to the list, or switch registration to open. Also check the App Users list: a suspended user stays suspended.

That user's account has been suspended or removed in your App Users list. Restore them there and they can sign in again immediately.

Your app is at its plan's user cap (20 signed-in users on Free). Remove unused accounts, or upgrade the plan to lift the cap.

Email codes and links are valid for a short window. Have them request a fresh one and use it promptly. If the email never arrives, have them check spam, and check that you have not restricted registration to a list they are not on.

A temporary platform-side condition on walled apps. It typically clears on its own within moments; if a user reports it persisting, contact support with your project ID.

Auth setting changes apply live immediately, but a new sign-in page or auth-dependent code in the app itself waits for the next publish. Publish, then test the live flow in a private browser window.

A privacy-class question, and worth fixing before anything else: the table is shared (or public) when it should be private per user. Tell the agent precisely who should see what, and verify with two test accounts. See How data privacy works.

Transient failures retry and heal on their own. If a migration is still failing after its retries, the Migrations section shows the exact migration and a plain-language reason. Ask the agent to fix that migration. Publishing is blocked until the schema is healthy again, deliberately, so a broken schema never ships.

The preview and the published app share your app's database, so real rows appear in the preview and test rows you create while building are real too. Delete test rows from the Database panel before launch, or ask the agent to clear a table.

The mirror image of the privacy problem above: the table is private per user when it should be shared. Same fix, in the other direction; tell the agent who should see what.

Check whether the app has a delete-confirmation or archive pattern first (ask the agent). Vaulter does not keep automatic row-level backups you can restore from, so treat the Database panel's delete actions as permanent. For bulk safety before an experiment, ask the agent to copy the table.

Schema changes are code changes: ask the agent to remove it, or Undo the change that added it. A column that is dropped disappears with its data, so say if anything in it must be kept.

DNS changes take minutes to hours to propagate, and the Domains panel keeps checking automatically. If it is stuck well past that, re-check each record's exact name and value against what the panel shows, and delete old conflicting records on the same name. The DNS reference lists the usual culprits.

SSL certificates are issued automatically once DNS points correctly, and issuance can lag connection by a few minutes. If the warning persists past half an hour, disconnect and reconnect the domain in the Domains panel to restart issuance.

Each form needs its own DNS record. Check the panel's record list covers both, and that both records exist at your DNS provider exactly as shown.

Purchased domains connect automatically, including DNS, but registration itself can take a little while to complete at the registry. Check the Domains panel for status; no action is needed from you.

DNS caching: visitors' networks remember the old records for up to a day. It expires on its own. To force the point sooner, also remove the records at your DNS provider.

Reconnect the service in the connector panel; an expired or revoked authorization is the usual cause. If the failure names a missing permission, the reconnect flow will request it.

Check the service's own status first (Stripe, Slack, and the rest have status pages), then reconnect. If the connector was working and nothing changed on your side, a reconnect refreshes credentials and resolves most cases.

Connector calls are rate limited per app to protect both sides (60 calls per minute). A burst of retries in your app's code is the usual trigger; the limit clears within the minute. If you set an owner spend quota on a connector and it is exhausted, calls stop with a payment-required error until the 30-day window moves or you raise the quota.

The catalog covers 27 services, and the Custom API connector reaches any other HTTP service with an API key. Describe the service and what you want to do with it, and the agent wires it through Custom API.

The daily limit spreads your monthly pool across the period (20 percent of your monthly allowance per day on Starter and Pro, 300,000 tokens on Free). Nothing is lost; building with AI resumes the next day. Top-up tokens are exempt from the daily limit, so a top-up unblocks you immediately.

The pool resets on your billing date. Until then: buy a top-up (never expires, spent after the monthly pool), move up your plan's token ladder, or keep working token-free (editing code by hand, Edit Mode style changes, and everything non-AI stays available).

Check the model: Vaulter Max spends fastest, Mini slowest. Check the habit: vague requests cost multiple attempts, and one precise request is the cheapest. And remember that automatic repairs are never billed, so auto-fix is not the culprit.

Plan changes apply to your workspace, and the Tokens panel (Settings → Tokens) reads live from it. Reload once; if the panel still shows the old plan after a successful payment, contact support with your workspace name.

Teams workspaces have per member budgets and a circuit breaker that stops any single member from spending more than a share of the remaining pool in a few hours. Set a monthly budget for that member in workspace settings, and review per member usage in the workspace analytics.

Codes come from noreply@vaulter.run; check spam and promotions folders. Codes expire after 10 minutes, and requesting a new one invalidates the old, so use the newest email.

Both routes lead to the same account when the email address matches. Use whichever is convenient; there is no password to remember either way.