Flex Consumption Node 24: BuildSuccessful then RuntimeFailed for minimal HTTP app

The supported next step without another deployment or configuration change is to run the Flex-aware startup detector and then open an Azure technical support request with advanced diagnostics enabled so Microsoft can correlate the failed platform deployment and retrieve backend host/controller evidence.

1. Capture the existing failure

From the affected Function App:

1. Select Diagnose and solve problems.
2. Run Flex Consumption Deployment.
   • Preserve the deployment timestamp, terminal status, extended error code, package status, and instance counts.
   • This detector is specifically documented for Flex and reports deployment history, package status, and troubleshooting recommendations.^1^
3. Run Function App Down or Reporting Errors (Preview).
   • Open Availability and Performance if the portal presents categories.
   • Select the failure window containing BuildSuccessful followed by RuntimeFailed.
   • Export or capture startup events, runtime/language validation, mandatory-setting results, managed-identity checks, storage checks, and SyncTrigger findings. The detector supports Flex and evaluates those specific areas.^2^
4. Save the Function App Activity log entries covering provisioning, deployment, instance replacement, and runtime failure.

Kudu/SCM logs are not the supported fallback here: Microsoft’s troubleshooting documentation explicitly excludes Flex Consumption from the Kudu logs diagnostic path.^2^

failedInstancesLogs

The property is documented only as a list of URLs for instances that failed to provision.^3^

Therefore:

• It applies when the deployment controller records one or more failed provisioning instances and publishes their log URLs.
• It is not documented as a guaranteed host/Node-worker exception channel.
• An empty field does not establish successful runtime startup. In particular, a terminal controller failure with zero recorded failed instances can leave no URL to expose.
• The documentation does not specify exactly when Flex populates it or its retention/access behavior. Support must inspect the deployment-status record and backend correlation for that determination.

2. Networking requirements

Operator deployment access and platform startup access are separate:

• Operator/runner access: inbound restrictions must allow the machine or deployment agent to reach the deployment endpoint. A private endpoint also requires private DNS resolution.^4^
• Platform access: with Function App access restrictions, Microsoft documents allowing the AzureCloud service tag. This permits Azure platform-originated traffic without allowing anonymous traffic from the entire internet.^5^
• Outbound host access: if host or deployment storage is network-restricted, Flex must use VNet integration and working private DNS/routes to reach that storage. Inbound restrictions do not provide outbound connectivity.^5^

A supported restricted design is therefore:

• Keep function authorization enabled.
• Retain selected inbound IP/VNet rules or use a private endpoint.
• Allow AzureCloud for required platform traffic.
• Give the deployment operator/agent an allowed route to the deployment endpoint.
• Use VNet integration plus private DNS when storage is private.

Those are configuration changes, so treat them as a comparison target for the current state rather than authorization to apply them.

3. Node 24 and managed identity

Node.js 24 is GA and explicitly supported on Flex Consumption, so Node 24 alone does not identify the cause.^6^

There is a closely matching 2026 Flex report involving successful build/candidate startup followed by RuntimeFailed/ExpectationFailed; it was redirected to Azure Support as a platform-level deployment issue. It does not establish a Node 24-specific defect.^7^

User-assigned identity for Flex host storage is supported. For AzureWebJobsStorage, Microsoft documents Storage Blob Data Owner as the minimum host role and Storage Table Data Contributor for persisted diagnostic events; missing the latter can suppress useful diagnostic events.^8^ Deployment storage using a user-assigned identity separately requires Storage Blob Data Contributor.^9^

Support should compare the effective failed-instance settings and identity assignments against the provisioning source; that unresolved comparison currently prevents attributing the failure to either configuration or platform.

4. Secure escalation

Open the request from Function App → Support + Troubleshooting → Create a support request, select the affected subscription/resource, and enable Advanced diagnostic information. This is the supported mechanism granting Azure Support access to relevant resource logs.^10^

Provide privately:

• UTC failure window and region
• Function App resource ID and deployment/correlation IDs
• Detector exports and Activity Log
• Sanitized deployment-status JSON
• Package hash and dependency manifest
• Confirmation that no HTTP invocation occurred
• Request for the first attributable controller, host, specialization, trigger-sync, or Node-worker exception

Additional files can be uploaded after case creation; the portal supports up to five files and documents its privacy and size restrictions.^11^

References

1. Azure Functions Flex Consumption plan hosting
2. Troubleshoot Azure Functions app down or reporting errors
3. ICsmDeploymentStatus.FailedInstancesLog Property-Definition
4. Continuous deployment for Azure Functions (flex-consumption-plan)
5. Azure Functions networking options (flex-consumption-plan)
6. Compare Azure Functions runtime versions (programming-language-javascript)
7. Flex Consumption controller returns RuntimeFailed / ExpectationFailed ...
8. Configure connections to remote services in Azure Functions (functions-auth-identity)
9. Create and manage function apps in the Flex Consumption plan (programming-language-java)
10. Create an Azure support request
11. Manage an Azure support request