Azure Functions Flex Consumption: SyncTriggers fails with 100-second timeout, causing partially successful deployment and timer triggers not executing

Question

Azure Functions Flex Consumption: SyncTriggers fails with 100-second timeout, causing partially successful deployment and timer triggers not executing

azuregk 0

Issue:

We are experiencing an issue with an Azure Function App running on the Flex Consumption plan using Linux and Python.
The deployment package uploads successfully.
The deployment then remains at: [Kudu-RemoveWorkersStep] starting.
The deployment is eventually reported as partially successful.
The deployment error is: The request was canceled due to the configured HttpClient.Timeout of 100 seconds elapsing.
Azure Diagnostics reports: System.Threading.Tasks.TaskCanceledException.
The diagnostic message is: SyncTriggers operation failed. A task was canceled.

Environment:

Azure Functions Flex Consumption plan
Linux hosting
Python runtime
VNet Integration enabled for outbound connectivity
Private Endpoint enabled for inbound connectivity
NAT Gateway attached to the VNet Integration subnet
Microsoft.Storage service endpoint enabled
AzureWebJobsStorage configured
Application Insights configured
ZIP deployment through Azure CLI and Azure DevOps

Impact:

Timer-triggered functions are not executing.
Trigger synchronization fails repeatedly.
Deployments are reported as partially successful.
Manual execution of the functions works successfully.
Scheduled processing cannot run automatically.

Additional diagnostic findings:

System.Threading.Tasks.TaskCanceledException occurred repeatedly during SyncTriggers.
The readiness health check reported: No script host available.
The readiness error code was: NoScriptHost.
The web host lifecycle status was: Unhealthy.
The web host lifecycle description was: Stopping.
The web host lifecycle error code was: Stopping.
The liveness health check also reported the web host as unhealthy and stopping.
The AzureWebJobsStorage health check remained Healthy.
Another exception reported was: Microsoft.AspNetCore.Connections.ConnectionAbortedException.
The corresponding message was: Exception encountered while listening to EventStream. The HTTP/2 connection faulted.

Troubleshooting performed:

Confirmed that the deployment package uploads successfully.
Confirmed that manual function execution works.
Verified the timer schedules and related Function App settings.
Tested timer triggers with use_monitor=True.
Tested timer triggers with use_monitor=False.
Tested timer triggers with run_on_startup=True.
Restarted the Function App.
Redeployed the application package.
Reviewed Application Insights and Azure Function diagnostics.
Confirmed that AzureWebJobsStorage reports a Healthy status.
Confirmed outbound connectivity through the NAT Gateway.
Confirmed that the Microsoft.Storage service endpoint is enabled.
Reviewed the Function App managed identity permissions.
Verified the Application Insights connection configuration.
Assigned the Monitoring Metrics Publisher role to the Function App managed identity at the Application Insights resource scope.
Temporarily removed the Function App Private Endpoint and are testing the deployment while leaving VNet Integration and the remaining configuration unchanged. Is this a known issue with Azure Functions Flex Consumption?

0 comments

2 answers

Your answer

Answer 1

Yes. The context shows Flex Consumption deployment and trigger-sync issues can occur, and there are two relevant patterns for this scenario:

Trigger synchronization problems are a known diagnostic area on Flex Consumption The Flex Consumption guidance explicitly calls out AzureActivity for diagnosing trigger registration issues and notes that sync trigger failures are common. For a non-HTTP trigger that is not firing, the guidance also says related exceptions can appear in scale-controller traces.
A successful package upload does not guarantee a healthy function host A documented Flex Consumption case shows deployment reported as successful while new instances still indexed 0 functions, and the recommended next steps were to verify the deployed package, confirm trigger synchronization completed, and use the Flex Consumption Deployment diagnostic in Diagnose and solve problems. If package contents and trigger sync are correct but the issue reproduces across multiple host instances, the guidance is to open a Microsoft support request with deployment ID, host instance IDs, timestamps, region, runtime/host versions, and deployment/host logs.
SCM/Kudu behavior on Flex Consumption is transient Another documented Flex Consumption answer states that Kudu is only available during an active deployment and is recycled afterward. That aligns with deployment-stage observations around Kudu steps, but the core issue in this case is still the failed trigger synchronization and unhealthy host state.
Regional platform issues have affected Flex Consumption before The context also includes a West Europe Flex Consumption incident that caused 500 errors, timeouts, and high latency. That does not prove the current issue is the same incident, but it confirms that platform-side Flex Consumption issues have occurred.

Based on the supported guidance, the most relevant next actions are:

In the Azure portal, open the Function App and run Diagnose and solve problems → search for Flex Consumption Deployment. Check deployment history, package status, and troubleshooting recommendations.
In Application Insights → Logs, inspect:
- AzureActivity for trigger registration and sync-trigger operations.
- traces for host startup, deployment initialization, listener, and trigger messages.
- exceptions for runtime failures.
- dependencies for outbound failures such as DNS, TLS, or authentication issues.
For the timer trigger specifically, query traces for messages containing listener or trigger, because the guidance says non-HTTP triggers that are not firing commonly surface there.
Verify that the deployed package contains the expected function app files and dependencies produced by the remote build, and confirm trigger synchronization completed.
If the package is correct, AzureWebJobsStorage is healthy, and multiple deployments or host instances still show failed sync or unhealthy host behavior, escalate to Microsoft support with:
- deployment ID
- host instance IDs
- timestamps
- region
- runtime and host versions
- deployment logs
- host logs

The context supports treating this as a known Flex Consumption troubleshooting pattern, and if package validation plus trigger-sync checks do not resolve it, as a case that may require platform-side investigation.

Answer 2

Hi @azuregk

Thank you for reaching out to Microsoft Q&A and also for laying out the diagnostics so clearly. From the symptoms, I would focus first on Functions host startup rather than the timer configuration itself.

Flex Consumption supports both inbound private endpoints and outbound VNet integration, so that combination is not documented as unsupported. However, NoScriptHost followed by Stopping means the Functions host is not becoming ready. When that happens, SyncTriggers cannot complete, and timer triggers will not be registered or run. Changing use_monitor or run_on_startup will not resolve that underlying host-readiness failure.

I think removing only the Function App private endpoint is a sensible isolation test. After redeploying, check whether:

SyncTriggers completes successfully.
Host health no longer reports NoScriptHost or Stopping.
Timer functions are discovered and begin firing normally.

If the app recovers, review the private-endpoint DNS and deployment-access path. Azure Functions documentation notes that private endpoint names must resolve correctly, and VNet-integrated apps use the DNS configuration of the VNet.

I would also verify the integration subnet itself: for Flex, it must be a dedicated subnet delegated to Microsoft.App/environments, sized at least /27 for a single app (/26 is recommended for multiple apps or higher scale). That subnet cannot also host private endpoints or service endpoints. For AzureWebJobsStorage, confirm that every required storage endpoint is reachable through the configured network path and DNS. The Functions runtime depends on its default storage account to maintain app health; when Storage private endpoints are used, Microsoft documents file, blob, and table as required, with queue also needed for Durable Functions.

In Application Insights, correlate the deployment timestamp and find the first startup error in traces, exceptions, and dependencies, before the SyncTriggers cancellation. In my experience, that first failure is much more useful than the final 100-second timeout and usually exposes a DNS, routing, dependency, package, or runtime-startup problem.

If the host still reaches NoScriptHost/Stopping after the inbound private endpoint is removed and a known-good package is deployed, I would open an Azure support request. Include the Function App resource ID, region, UTC timestamps, deployment/correlation IDs, full host and Kudu logs, Application Insights startup telemetry, and the VNet/private-endpoint/DNS design. At that point, support can determine whether a platform-side lifecycle or trigger-synchronization investigation is needed.

References:

Please 'Upvote' (Thumbs-up) and 'Accept' as an answer if the response was helpful. This will be bhelpful to other community members who face the same issue.

Best regards, Andrew S Taylor