Azure Functions Flex Consumption：CLIとHTTP応答は成功するが、ARMの配布状態がRuntimeFailedになる

Question

Azure Functions Flex Consumption：CLIとHTTP応答は成功するが、ARMの配布状態がRuntimeFailedになる

Morimoto Ryosuke 20

Azure Functions Flex Consumptionへの配布について、実際のアプリ動作とARMの配布状態が一致せず、配布完了の判断方法を確認したく質問します。

検証環境はLinux／Node.js 22、Japan East、更新方式はRecreateです。Azure CLI 2.87.0から次の方法で配布しています。

az functionapp deployment source config-zip ... --src <package.zip> --build-remote false

これまでの検証では、CLIは成功で終了し、配布した版で認証付きHTTP処理、SQLへの保存・再読、版別のtelemetryを確認できました。旧版への復旧後も既存データを再読できています。一方、ARMの配布状態では、20分のタイムアウトによるRuntimeFailedが記録されました。

複数回の配布による影響を切り分けるため、同じパッケージを一度だけ配布する追加検証も行いました。

・CLIはexit code 0で終了し、Deployment was successful.と表示されました。

・Flex Consumptionの配布診断では、package upload、worker reset、trigger syncが成功していました。FDM監視はskipと記録されていました。

・ARMの状態はBuildSuccessfulからRuntimeStartingへ進みましたが、instance数は成功・失敗・処理中ともに0でした。

・アプリへの無認証GETは10回とも想定したJSON形式の401を返し、telemetryの件数・status・対象版も一致しました。

・停止後に同じ配布IDを照会すると、RuntimeFailed、ExpectationFailed、extended code 04916、20分のタイムアウトが記録されていました。

なお、追加検証は25分観測する予定でしたが、こちらの観測スクリプトがerrors配列を正しく扱えず、約22分で中断してアプリを停止しました。最後の停止前応答を保存できていないため、RuntimeFailedへの遷移と停止操作の厳密な前後関係は未確認です。

伺いたいのは次の2点です。

Flex ConsumptionのRecreate配布では、CLI・配布診断・対象版のHTTP応答が成功していても、ARMがこのようなRuntimeFailedになる場合があるのでしょうか。FDM監視のskipやinstance数が0のままであることも関係するでしょうか。
この状態で配布・ロールバックの完了を判断するには、どの情報を確認するのが適切でしょうか。実際の配布不成立や一部instanceの問題を見落とさない確認方法を知りたいです。

一般的なデプロイのトラブルシューティングは確認し、アプリ設定も照合済みですが、この状態の解釈は分かりませんでした。参考資料や、追加で確認すべき診断項目をご存じでしたら教えていただけると助かります。

0 件のコメント

質問作成者が受け入れた回答

0 件の追加の回答

お客様の回答

Answer 1

Tejaswini Billakurthi 760 Microsoft 外部スタッフモデレーター

Hi @Morimoto Ryosuke ,

Thank you for reaching out to Microsoft Q & A !

Your authenticated HTTP and SQL write/read tests, together with version-specific telemetry, show that the deployed version executed successfully for the requests tested. However, they do not establish that every instance is healthy or explain the ARM deployment failure.

For Recreate, Microsoft’s states that there is “No completion signal” and recommends monitoring instance logs to track when the original instances stop emitting logs. This is separate from the reported RuntimeFailed / ExpectationFailed / 04916 after 20 minutes—the documentation does not establish that this failure is expected or harmless.

I haven’t found Microsoft documentation that links this specific failure to FDM monitoring being skipped or the instance counters remaining 0. I would therefore focus the next validation on:

Capture the complete ARM response before stopping the app. Adjust the observation script to handle errors as an array and preserve responses for the same deployment ID, including any failedInstancesLogs. Verify the UTC sequence of the failure and stop operation; the current evidence does not establish their ordering.
Repeat your authenticated HTTP and SQL checks during that same window, particularly after RuntimeFailed appears while the app remains running. Correlate the release identifier and cloud_RoleInstance with startup errors and exceptions. The 10 expected JSON 401 responses validate the rejection path, rather than the authenticated workflow. Instance-log checks can provide additional evidence, but the absence of errors alone does not prove that every instance is healthy.
Use the same validation for rollback, checking the previous release identifier, required configuration, and SQL compatibility. Microsoft’s explains that redeploying previous code does not undo database data or schema changes.

Until the discrepancy is explained, I would record the result as “application checks passed; deployment completion remains unverified”, rather than treating CLI exit code 0 as sufficient.

Could you share the redacted pre-stop ARM response, deployment ID, polling API version, FDM skip log entry, and UTC timeline? Also, do authenticated requests continue to succeed after RuntimeFailed appears? Please remove credentials, connection strings, and signed log URLs before posting.‌

Please "Upvote the Answer" if this information helped you. This will help us and others in the community as well.

Morimoto Ryosuke 20 評価のポイント

2026-09-20T15:55:49.4366667+00:00
Thank you for the clarification. We agree that successful application checks do not establish deployment completion or the health of every instance.

Our existing evidence does not establish the ordering of the ARM failure and the stop operation, or whether authenticated HTTP/SQL operations continued to succeed after RuntimeFailed appeared. We will keep those points explicitly unverified.

Before arranging another controlled test, could you clarify the following?

Meaning of the failure: What condition does RuntimeFailed / ExpectationFailed / 04916 represent for a Flex Consumption deployment using Recreate? Does it indicate a specific failed health check, a timeout waiting for a platform condition, or something else?

Required diagnostics: Which ARM polling API version, response fields, and diagnostic logs would be most useful for investigating this error? In particular, how should we interpret “FDM monitoring skipped” and instance counters remaining at zero? If their meaning is not publicly documented, please indicate that limitation.

Escalation: If we capture the complete pre-stop ARM response and demonstrate that authenticated application operations still succeed after RuntimeFailed, would an Azure support case be the appropriate next step to investigate the discrepancy? What additional evidence should we prepare for that case?

We will redact credentials, connection strings, personal information, and signed log URLs before sharing any evidence.
Tejaswini Billakurthi 760 評価のポイント Microsoft 外部スタッフモデレーター

2026-09-21T09:47:29.48+00:00
こんにちは @Anonymous

別の管理検査を手配する前に、正確な解釈と診断要件を求めるのは正しい判断です。

1. の意味 RuntimeFailed、 ExpectationFailed 、04916

Get Production Site Deployment Status REST APIはデプロイステータスとして含まれています。しかし、このリファレンスには基礎となる障害条件が定義されておらず、特定のFlex Consumption展開失敗にマッピングされたMicrosoftの公開ドキュメントも見つかりませんでした RuntimeFailed 。ExpectationFailed / 04916

報告された 20分のタイムアウトだけでは、どのプラットフォーム条件が満たされなかったかを特定することはできません。プラットフォーム側の証拠なしに、これを確認されたアプリケーションのヘルスチェック失敗や無害な報告問題として片付けることはありません。

Recreateドキュメントの**「完了信号なし」**という文はサイト更新戦略を説明しています。 RuntimeFailed しかし、デプロイステータスの結果が期待されることは示していません。

2. 展開状況ポーリングおよび診断証拠

別の制御テストが実施された場合、文書化されたポーリングオプションとして「**本番サイトのデプロイメント状況を取得する」が、**APIバージョン 2025-03-01 と観察期間中同じデプロイ操作GUIDを使い続けます。これはAPIバージョン変更による修正案ではなく、文書化された収集オプションです。

各回答を完全に保持し、特に以下の項目を保持してくださいproperties:

deploymentId および status

入れ子状の詳細やerrors任意の、、codeおよび message 値extendedCodeを含む完全な配列

failedInstancesLogs — プロビジョニングに失敗したインスタンスのログ用URL

numberOfInstancesSuccessful

numberOfInstancesFailed

numberOfInstancesInProgress

また、HTTP応答ステータス、UTCコレクションタイムスタンプ、返されたリクエストや相関識別子も記録してください。RESTレスポンススキーマは、現在実行中のすべてのアプリケーションインスタンスのインベントリではなく**、デプロイメントの枠**組みでカウンターを定義します。

「FDM監視がスキップされた」やRecreateシナリオで3 ** つのカウンターすべてが0のままだったと説明するMicrosoftの公開ドキュメントは見つかりませんでした ** 。これらの観察は診断証拠として保持してください;どちらも検証の成功を証明するものではなく、アプリケーションインスタンスが実行されなかったことを証明するものではありません。

同じUTCウィンドウの場合、以下を保持します:

Flex Consumption Deploymentの診断レポートは、FDMエントリや周辺のデプロイイベントを含む問題を診断・解決します。この検出器はデプロイガイダンスに記載されています。

利用可能なアプリケーションインサイトrequests、 traces exceptions dependenciesと、リリース識別子、運用ID、 cloud_RoleInstance 利用可能な場合などが含まれます。

開始、停止、設定変更のためのアクティビティログエントリー。

認証済みのHTTPおよびSQLテスト結果でアプリケーションのバージョンを特定します。

Flex Consumption モニタリングガイダンスにはこれらのログソースが説明されています。

新しい再現の場合は、アプリが稼働し続けた後に ** 認証RuntimeFailed済みHTTP/SQLの結果をキャプチャ**します。タイムスタンプ付きの応答、テスト結果、開始/停止レコードは、その複製の順序を確立できますが、前回のテストの順序を遡って決定することはできません。

3. Azure サポート

この未解決の不一致を調査するには、Azure Functionsの技術サポートケースが適切です。もう一度管理された複製が必要になる必要はありません。既存の証拠を提出し、Azure サポートに再複製が必要かどうか判断してもらいましょう。

上記の診断パッケージに加えて、以下が含まれます:

サブスクリプションIDと機能アプリリソースID

展開IDとUTCタイムライン

デプロイコマンドおよびパッケージのハッシュまたはリリース識別子

環境詳細: Azure CLI 2.87.0、Linux、Node.js 22、Japan East、Recreate、 --build-remote false

前回のテストについては、以下の2点が未確認のままです。その後の再現による所見は別途記録されています:

RuntimeFailed Functionアプリが停止される前に起こったかどうか。

認証済みHTTP/SQL操作が正常に継続されたかどうか RuntimeFailed が明らかになりました。

したがって、現在の結果は次のようにまとめることができます。

デプロイされたアプリケーションバージョンは機能チェックに合格しましたが、ARMはを報告しました RuntimeFailed。プラットフォーム展開状況の不一致は未解決のままです。

Azureのサポートリクエストプロセスを使い、サポートに条件を特定し、04916FDM/カウンターの挙動を説明し、デプロイステータスレコードがこのデプロイメントを正確に表しているかを判断してもらいます。技術サポートにはサポートプランと適切な権限が必要です。

もしこの情報が役に立ったなら、ぜひ「アップボート」してください。これは私たちやコミュニティの他の人々にも役立ちます。
Morimoto Ryosuke 20 評価のポイント

2026-09-21T11:40:03.73+00:00

Hi Tejaswini,

Thank you for the detailed explanation and diagnostic guidance. Your clarification helped me understand the distinction between successful application-level checks and the unresolved ARM deployment status.

I’ll consider opening an Azure support request with the existing evidence to investigate the RuntimeFailed / ExpectationFailed / 04916 result, and let the support team advise whether another controlled reproduction is needed.

Thank you again for your time and assistance.

Azure Functions Flex Consumption：CLIとHTTP応答は成功するが、ARMの配布状態がRuntimeFailedになる

1. の意味 RuntimeFailed、 ExpectationFailed 、04916

2. 展開状況ポーリングおよび診断証拠

3. Azure サポート

0 件の追加の回答

お客様の回答

1. の意味 `RuntimeFailed`、 `ExpectationFailed` 、`04916`