MAI-Transcribe-2 with diarization returns 408 RequestTimeout even for 10-second audio (Southeast Asia)

Question

MAI-Transcribe-2 with diarization returns 408 RequestTimeout even for 10-second audio (Southeast Asia)

Mobidoc Adwel 0

Since 2026-11-05 ~03:00 UTC, every MAI-Transcribe-2 request with diarization enabled on our Speech resource in southeastasia fails with HTTP 408 after ~240 seconds:

MAI service returned an error: RequestTimeout - { "error": { "code": "Timeout", "message": "The operation was timeout." } }

Endpoint: POST /speechtotext/transcriptions:transcribe?api-version=2025-10-15

Minimal repro (10-second mono Opus/OGG file):

definition	result
`{"enhancedMode":{"enabled":true,"model":"MAI-Transcribe-2"},"diarization":{"enabled":true}}`	408 after 240 s (repeated 4+ times, 05:3x-07:2x UTC)
same, diarization disabled	200, but 132 s for 10 s of audio
no enhancedMode (standard fast transcription)	200 in 0.9 s
MAI-Transcribe-2 once at 07:05 UTC	200 in 96 s, then back to 408

Before this incident the same pipeline (15-minute chunks, diarization on, phraseList, word timestamps, clean style) was healthy: a 72-minute meeting finished in 26 s on 2026-11-04 ~02:00 UTC. Latency started degrading around 2026-11-04 08:00 UTC (a 13-minute recording took 224 s) and turned into consistent 408s on 2026-11-05.

This is not the known ">15-minute diarization" limitation: it fails on a 10-second file, and our real chunks are <=15 minutes, which worked fine the day before.

Impact: all meeting transcriptions in our organization have been blocked for 5+ hours.

Questions:

Is there a known degradation of MAI-Transcribe-2 in Southeast Asia?
Is there an ETA or a recommended region to fail over to?

0 comments

MAI-Transcribe-2 with diarization returns 408 RequestTimeout even for 10-second audio (Southeast Asia)

Your answer