Free 10-minute diagnostic
AI-built app works in preview. Production breaks.
Do not start by reprompting the whole app or pasting credentials into a chat. First locate the boundary that changed: build output, environment, origin, runtime binding, or the exact production path.
No login - no secret upload - no automated scan - no uptime promise
The deployment chain
A working preview proves only the preview.
- 01Build emitted
The expected route and server artifact exist in the selected output directory.
- 02Environment supplied
The production deployment received the required variable and binding names in the right scope.
- 03Origin allowed
Public URLs, API origins, callbacks, and authentication redirects name the production host.
- 04Runtime connected
The deployed server can reach its authorized database, storage, queue, or provider binding.
- 05Path accepted
The same production URL passes one repeatable user-journey test after a fresh deployment.
10-minute checklist
Find the first unproven production boundary.
Use synthetic data and record names, statuses, and timestamps. Keep tokens, passwords, private keys, and customer data out of screenshots and messages.
- 01
Reproduce one exact production path
Open the deployed URL, perform one controlled journey, and record the timestamp, route, visible result, expected result, and request status. Do not use a broad “the app is broken” description.
- 02
Confirm the deployed build
Compare the successful preview command with the production build command, root directory, framework preset, and output directory. Verify that the failing route was actually emitted.
- 03
Inventory variable names by environment
Compare required names across local, preview, and production without copying values. A corrected production variable may require a new deployment before the running app can see it.
- 04
Check the production origin and redirects
Look for localhost, preview domains, old domains, and overbroad wildcards in site URLs, API bases, CORS rules, OAuth callbacks, email links, and password-reset redirects.
- 05
Verify runtime bindings and migrations
Confirm the deployed environment has the expected binding names and current migration state. Use one synthetic operation; do not test by exposing or overwriting real customer records.
- 06
Redeploy, rerun, then roll back if uncertain
Create a fresh deployment after environment changes, rerun the same acceptance test, and preserve the previous working version. A different test cannot prove the original failure is repaired.
Symptom map
Use the symptom to choose the next boundary.
| Production signal | Likely boundary | Safe evidence to collect |
|---|---|---|
| Route returns 404 | Wrong output directory, missing route artifact, or router fallback | Build command, output path, deployed file list, and exact failing URL |
| Value is undefined | Build-time variable is absent, misnamed, or scoped to another environment | Variable names and environment scope only; never copy secret values into chat or logs |
| Login returns to localhost | Production site URL or allowed redirect path is wrong | Exact production origin, requested callback URL, and provider allow-list entry |
| Fetch or CORS fails | Frontend API base, origin policy, or server/runtime boundary differs | Browser request URL, status, response headers, and bounded server event |
| Database or storage fails | Production binding, migration, permission, or resource ID differs | Binding name, deployment environment, migration state, and a synthetic read/write result |
Official deployment references
Production and preview are separate configuration surfaces.
Cloudflare documents build commands, output directories, environment-specific bindings, and deployment variables. Vercel documents separate variable scopes and that changes apply to new deployments. Supabase recommends an exact production redirect path while reserving broad wildcards for previews and local development.
Cloudflare Pages build configuration ->Cloudflare Pages bindings ->Vercel environment variables ->Supabase redirect URLs ->
Stop before changing production
Escalate instead of guessing when:
- there is no verified rollback or recent backup;
- the next step requires sharing a password, token, private key, or customer record;
- authentication, payments, regulated data, or access controls are involved;
- production ownership, deployment authority, or third-party permission is unclear;
- the failure cannot be reproduced with a bounded acceptance test.
Still missing the boundary?
Buy the diagnosis before buying the repair.
The $49 diagnosis maps one reproducible production path and returns a written repair recommendation. A repair pilot starts at $149 only after scope, funding, authorized access, acceptance evidence, and rollback are agreed.
Describe the production failure