In production, a Netlify function reads process.env.MY_KEY as undefined, or gets a masked value, although the same code works locally. Common causes: a scope that does not include Functions, a value set after the deploy, or a variable declared in netlify.toml.
On Pro and Enterprise plans, a variable can be limited to scopes such as Builds, Functions or Runtime. A variable scoped to Builds is visible to the build but not to the function at runtime.
How to tell: The variable is listed for the Builds scope but not for the Functions scope.
Each deploy, including Deploy Previews and branch deploys, uses the variable values that were set when it was deployed. Adding a variable in the UI does not change a deploy that already exists.
How to tell: The variable appears in the UI, but the running deploy is older than the change.
Variables declared in netlify.toml are not available to serverless functions. They can look correct, because the value is in the file and in the build. The CLI's env:list is documented as including netlify.toml values, so it can show the key too.
How to tell: The function logs the key as unset, and the key is declared in netlify.toml with no matching site variable that includes the Functions scope in the UI.
Secret values are write-only, and code running outside Netlify's hosted systems gets masked versions. Secret values must also be set to explicit deploy contexts and scopes.
How to tell: The value is a masked placeholder instead of your real key, while non-secret variables resolve.
Log a boolean, not the value, and read it with process.env. Trigger the function on the deploy that fails, then check the function logs.
export default async () => {
console.log("MY_KEY set:", Boolean(process.env.MY_KEY))
return new Response("ok")
}env:list is documented as including netlify.toml values, so a key shown here may come from the file rather than from a site variable with the Functions scope. Compare the output with the variable's entry in the UI. The log from step 1 shows what the function actually receives.
netlify env:list --scope functions --context productionOn Pro and above, open the variable under Project configuration > Environment variables and confirm its scopes include Functions. A variable limited to Builds does not reach the function at runtime.
If the key is declared in netlify.toml, set it as a site variable with the Functions scope instead. The command below uses a placeholder. Keep real values out of the repository.
netlify env:set MY_KEY <value> --scope functions --context productionSet secret variables with explicit contexts and scopes, and test them from a deploy hosted on Netlify. A local netlify build does not include the raw values, and the secret flag cannot be removed once set.
Changes to variables take effect on the next build and deploy. Retest the function on the new deploy, not the old one.
Quick check: grep -n MY_KEY netlify.toml; check the function log for Boolean(process.env.MY_KEY) on the failing deploy
4 of the 937 verified cases from the last 12 months in our data match this symptom (0.4%). How we collect and verify cases.
No. The Netlify docs state that variables declared in netlify.toml are not available to serverless functions, so set them in the UI, CLI or API with the Functions scope.
Yes. Each deploy uses the values that were set when it was deployed, so create a new deploy to apply updated values.
Secret values are write-only, and code running outside Netlify's hosted systems gets masked versions. Check that the function runs on a Netlify deploy and that the secret is set to explicit deploy contexts and scopes.
In Lambda compatibility mode, AWS's limit applies: the total size of all environment variables cannot exceed 4 KB.
Every cause and step above was checked against these pages on 27 Oct 2026.
This is one symptom of a wider failure pattern: Environment variables missing or empty in production: fixes. The guide covers every cause we see for it, on any stack.