Azure Video Translation: 337–361 seconds in NotStarted despite fast HTTP 201 — request engineering investigation

We are requesting review by a Microsoft engineer and escalation to the Azure AI Speech / Video Translation product team for a recurring delay after translation creation is accepted and before the iteration changes from NotStarted to Running.

Observed issue A short video can spend approximately 5.6–6.0 minutes in NotStarted even though the creation request returns HTTP 201 in less than half a second. The operations eventually succeed. We need evidence-based guidance on the cause and a supported mitigation; we are not claiming that cold start or model loading has been proven.

Workload and workflow

• Same original 70.875-second MP4, Romanian to Italian, one speaker.
• PlatformVoice: it-IT-Alessio:DragonHDLatestNeural.
• Submitted through our normal application UI, without changing application code or the translation workflow during these tests.
• Flow: Fast Transcription -> transcript review -> text translation -> Video Translation with supplied transcript/translation metadata -> iteration status polling -> local output/subtitle rendering.
• The same source transcript text was retained in these three runs. We are not claiming byte-identical internal Azure inputs or measuring Video Translation's automatic transcription path.
• The calling App Service had Always On enabled and Health Check configured at /health. Health requests returned HTTP 200 while the Video Translation iteration remained NotStarted. These checks concern our App Service, not the readiness of the managed Video Translation backend.

Measurements from three runs on 18 October 2026

NotStarted is measured from the first worker polling observation of NotStarted to the first observation of Running. Running is measured from that observation to the first observation of Succeeded. These are polling-based durations, not Azure internal transition timestamps. The Azure step includes preparation before polling, and the full application time additionally includes transcription, human review and local rendering; those totals must not be conflated with HTTP latency.

For run C, AzureDiagnostics recorded CreateOrReplaceTranslation HTTP 201 with a duration of 410 ms. State reads around the test were fast (approximately 40 ms on average in the resource-level diagnostics). Nevertheless the iteration spent 360.622 s in NotStarted. Fast Transcription took about 2.8 s and the preceding text translation about 0.9 s. No HTTP 429 or 5xx errors appeared in the diagnostics consulted for these runs.

Controls and limitations

• No deliberate worker restart was performed for runs B and C. Enabling Health Check before run A had caused a worker restart approximately ten minutes earlier, so run A is not a no-restart control.
• The application completion-to-next-submission gaps were approximately 5 h 44 min before B and 3 h 30 min before C. They are NOT clean Speech inactivity intervals: resource-wide diagnostics showed other translation activity during the gaps, and preparing the latest UI submission also generated a token request. Resource-level aggregate counts cannot all be attributed to our test job.
• Additional resource activity was also observed after run C had entered Running. We cannot identify its origin from the evidence available.
• Diagnostic ingestion can lag. Absence of a row in a partial query is not proof of no activity.
• Repeating the same video and keeping the caller healthy did not reliably eliminate the delay. This does not distinguish backend activation, scheduling/capacity, routing or caching.

Questions for Microsoft engineering

1. Is a recurring roughly six-minute NotStarted interval after a successful, fast HTTP 201 a known Video Translation behavior or issue? What can keep an accepted iteration in this state?
2. Which customer-accessible logs, correlation fields or metrics can distinguish queue/capacity waiting from backend activation, routing or other preparation? Request/response latency alone does not explain the asynchronous delay.
3. Is there a documented, supported way to reduce this delay without changing the application's functional workflow? If keep-alive reads, provisioned capacity, a region/voice choice or another setting are applicable, please identify the supported mechanism and its limitations rather than assuming App Service Always On warms Video Translation.
4. Does the supplied-metadata workflow described above require any additional operation to start processing promptly after creation?

Please have a Microsoft engineer review these measurements and, if necessary, escalate this report to the Video Translation product team. We would appreciate a service-specific human response and a reference to any known issue or documented mitigation. An AI-generated hypothesis alone cannot establish the internal cause.

This public report contains no subscription/resource identifiers, credentials, signed URLs, source media or raw logs. If further correlation evidence is needed, please identify an official secure channel and whether a no-cost investigation route is available.