Environment variables missing in production

1. Identify the missing setting.

   Open the failing request in Chrome’s Network panel and read its response, or inspect the host’s error log for the same action. In the code, find the environment variable name used by that integration. Record the exact spelling without copying the value.

2. Check the target environment.

   Open the host project’s environment settings. Find that name and verify that it applies to production, not only development or preview. Compare the project name with the deployment you are actually visiting.

3. Find when the value is read.

   Look at the code that reads the variable. In a Vite frontend, client-exposed VITE_ values are replaced at build time. A server-only setting belongs in server configuration. Read the framework’s rule before changing the variable prefix.

4. Compare configuration and deployment times.

   Open the current deployment’s details and build log. Check whether it was built before you added or changed the setting. Note the revision and environment so the next build can be checked against the same failing action.

WORKSA newly configured deployment completes the integration using the intended environment.

BROKENThe required name is absent, scoped elsewhere or missing from the deployment that reads it.

Ranked in the order to investigate, not by claimed frequency.

1. The production environment lacks the exact name.

   Add the setting to the intended production project and environment using the provider’s secure settings interface. Confirm the code uses the same spelling and that an empty value is not masking the absence.

2. The current build predates the setting.

   Create a new deployment after the configuration is saved. Reopen that deployment’s own URL and repeat the failing request before assuming the custom domain uses the new build.

3. A client bundle expects a server secret.

   Move the privileged call to your backend and keep the credential server-side. Expose only public configuration required by browser code; changing a prefix can change who receives the value.

• A correctly named variable can still point at the wrong project or test account. Presence alone does not prove the destination is correct.
• Host scopes and framework prefixes solve different problems. A value can be available during build yet deliberately unavailable to frontend code.

When to stop and hand it over

Hand over if you cannot identify whether the code runs in the browser or on the server, or if a fix would expose credentials. Send variable names, scope and deployment time with values redacted, together with the failed request’s status.