Troubleshoot functions

The function stays AwaitingDeployment

• No code has been deployed yet. Open the function's Code tab and choose Deploy.

• The first build failed. The portal does not show failed builds. List the namespace's builds with the CLI:

  bashCopy code

  stsh functions deployments my-namespace -g my-resource-group -o json

  A failed build has the phase Failed and a message that starts Build #… failed. The build's own output is not available to you.

• The runtime is .NET or Go. Their builds fail when the code comes from the portal — see Runtimes.

Node.js code is not compiled when it is built, so a mistake in it shows up when the function starts, not in the build.

A deploy changes nothing

When a later build fails, the previous version keeps running and the function's status does not change. Check the builds as above.

The function does not start

A replica that cannot start leaves callers waiting; after 30 seconds they get 504 Function cold start timeout. The status shows Error once the platform has seen the failing replica; a function that scales to zero can go on showing Sleeping. Common reasons:

• The code fails when it loads or starts — a syntax error, TypeScript-only syntax, an import of a module that is not built in, or a module with no function to call. Open Logs while the replica starts to see the error.
• Its secrets cannot be fetched. The namespace's managed identity needs Secrets Reader on every vault the function references, and the secrets must exist and be enabled — see Secrets and the managed identity. This failure happens before the function's own code runs, so Logs shows nothing for it.
• An image of your own does not answer GET /healthz on port 8080 — see What the image must do.
• The cluster has no room for another replica with the function's CPU and memory.

404 No function found at this path

• The path does not match the function's route. An HTTP function answers on its route and on paths below it — /hello and /hello/x, not /hellothere. The answer lists the routes that exist.
• The function is a timer function; those have no route.

404 or 503 without this JSON body

A 404 or 503 that does not carry the JSON answer above comes from the platform's ingress, not from the namespace's proxy: the request found no proxy to go to.

• The namespace's name is longer than 55 characters, so it has no proxy — see Basic Configuration.
• The proxy is down — see The namespace's proxy.

405 Method not allowed

The function does not accept the method; the Allow header lists the ones it does. Change the methods — see Change the route or the methods.

401

The function has authentication on and the call's token was missing or not accepted. Check:

• that the call sends Authorization: Bearer <token>;
• that Issuer URL is exactly the token's iss, with no extra slash at the end, and not empty;
• that the token's aud contains Audience, when one is set;
• that the token has not expired;
• that the issuer can be reached from the cluster.

See What is checked.

504 Function timed out

The handler ran longer than its time limit, 300 seconds unless you have shortened it — see Time limit. The handler keeps running after the caller gets the answer.

The first call is slow

A function with a minimum of 0 replicas sleeps, and the call that wakes it waits while it starts. A function built from the portal sleeps only until its first call; one that runs an image of your own sleeps again after every cooldown — see Scale to zero. Keep a function warm with a minimum of 1 — see Keep a function warm.

A timer does not run when expected

• Schedules run in UTC, whatever the Timezone field said — see Time zone.
• A run that is still going when the next time comes makes the proxy skip that time.
• Failed runs are not retried, and times missed while the proxy restarts are not made up.
• A timer that runs more than once at the same time is in a resource group with more than one function namespace: each namespace's proxy runs it — see Overlapping runs.
• A function stopped through the proxy's management interface runs no timer while it stays stopped — see How a request reaches a function.
• The function has to be able to start — see The function does not start.

Log from your handler so that every run shows in the function's Logs.

A namespace setting does not reach a function

• Environment variables set on the namespace reach running functions within about a minute. A sleeping function gets them the next time it is deployed or one of its settings is saved.
• Scaling, compute plan and authentication set on the namespace do not reach its functions at all today — see Namespace defaults and Namespace defaults.

The namespace's proxy

Every call and every timer run goes through the namespace's proxy, fnproxy-<namespace>, a single replica. While it is down, no function can be reached on the namespace's hostname and the proxy runs no timers. When it restarts, the timer schedules start over and its record of when each function was last used starts again from zero, so an idle function may run one cooldown longer before it sleeps.