Azure Batch Transcription: Consistent ~12h failure with "InvalidUri" for diarization-enabled jobs
Azure Batch Transcription: Consistent ~12h failure with "InvalidUri" for diarization-enabled jobs
Problem
I'm using the Azure Speech-to-Text Batch Transcription API with diarization enabled (maxSpeakers: 2, locale: ja-JP). A subset of jobs consistently fail with:
properties.error.code: "InvalidUri"
properties.error.message: "The recordings URI is invalid."
The key observation is that all failures occur after a remarkably consistent processing time of approximately 12 hours (mean: 11.9h, standard deviation: 0.46h, range: 11.2h–12.7h across 11 failures over 30 days).
Setup
- API Version:
2025-10-15 - Region: Japan East
- Audio source: Presigned URLs pointing to WebM audio files (7–21 MB), with a 24-hour expiry
- Configuration:
diarization: {enabled: true, maxSpeakers: 2},channels: [0, 1],wordLevelTimestampsEnabled: true
Failure Pattern
Across 11 failed jobs:
- 100% had diarization enabled
- Processing time from
createdDateTimetolastActionDateTime: 11.2h – 12.7h (stdev 0.46h) - The source URLs were confirmed valid and accessible at the time of failure (well within the 24h expiry)
- File sizes ranged from 7 MB to 21 MB — size alone does not correlate with failure
Successful Jobs (same configuration)
- Diarization-enabled jobs that succeed: mean 2.2h, max 8.6h
- Non-diarization jobs: mean ~6 minutes, max ~13 minutes, zero failures
Observations
- The failure time is too consistent (~12h ± 30 min) to be a random infrastructure issue — it strongly suggests a fixed internal timeout.
- There is a clear gap between the longest successful diarization job (8.6h) and the shortest failure (11.2h).
- The error code
InvalidUriseems misleading — the URI is valid and the source file is accessible at failure time. This appears to be a generic error returned when the service times out. - File size does not explain the pattern (a 7 MB file failed, a 15 MB file succeeded).
Questions
- Does Batch Transcription have an internal processing timeout (e.g., ~12 hours)? Is this documented anywhere?
- What does
InvalidUrispecifically mean in the context of aFailedtranscription? Does it indicate a download failure, or can it be returned when processing itself times out? - Is there any way to increase the processing timeout, or a recommended workaround for diarization jobs that may take longer to process?
- Are there known factors that cause diarization to take significantly longer (e.g., audio quality, speaker overlap, single-device recording of multiple speakers)?
Any insights from the community or Microsoft team would be greatly appreciated.
1 answer
-
Amanda Zhu 80 Reputation points
I don’t see Microsoft documenting a 12-hour Batch Transcription processing timeout. The documented behavior is that batch transcription is best-effort, may take up to 30 minutes to start, and up to 24 hours to complete. So the consistent 11–13 hour failures are worth treating as a service-side issue or unsupported edge case, not as a confirmed public timeout.
I would make 2 checks. First, diarization has a hard documented limit: source audio length can’t exceed 240 minutes per file when "diarization" or "diarizationEnabled" is selected. Second, Microsoft describes diarization as expected for mono audio with multiple voices and says the feature isn’t available with stereo recordings, so channels: [0,1] plus diarization is a config I’d simplify or split by channel before retrying.
For `InvalidUri Microsoft’s public enum only proves that InvalidRecordingsUri means the recordings URI was considered invalid. It doesn't prove that the code can represent a processing timeout. If the URLs remain reachable and the files are below the diarization length limit, you can open an Azure support case with the failed transcription IDs, timestamps, region, API version, and a note that the failures cluster around 12 hours despite 24-hour URL validity.