Significant delay in Azure Communication Services (ACS) call recording BYOS export for specific recording chunks.

Hi @Alexander Karaberov

Thank you for reaching us about the issue.

It sounds like your call hit the maximum chunk duration twice (triggering endReason: "ChunkMaximumTimeExceeded"), but the media blobs for chunks 0 and 2 didn’t actually land in your BYOS container until ~7 hours later, and the corresponding Event Grid notifications were delayed by the same amount of time. Normally you’d see media + metadata uploads and Microsoft.Communication.RecordingFileStatusUpdated events within minutes after each chunk finalizes, so a multi-hour delay is unexpected.

• For extended calls, ACS automatically splits recordings into multiple chunks. When a chunk reaches its maximum duration, it is finalized with the endReason set to ChunkMaximumTimeExceeded, which is expected behavior for long recordings.

• Metadata files (acsmetadata.json) can be created before the media blobs are fully processed. The media files and the "Microsoft.Communication.RecordingFileStatusUpdated" event are only generated once ACS finishes processing and exporting that chunk.

• The RecordingFileStatusUpdated event is intentionally emitted only when a chunk is fully finalized and ready for consumption, so its timing aligns with when the media blob becomes available.

That said, the public documentation does not define a guaranteed or maximum export latency for BYOS call recordings. A multi‑hour delay for specific chunks, while others complete earlier, is not explicitly documented and is not something customers are expected to design around.

That the delayed chunks were eventually exported and the corresponding events were raised, this strongly suggests a service‑side delay during recording finalization or export rather than data loss or a storage issue on your side. To determine the exact cause, a backend investigation by the ACS service team would be required.

Reference:
https://learn.microsoft.com/en-us/azure/communication-services/concepts/call-automation/call-recording/bring-your-own-storage
https://learn.microsoft.com/en-us/azure/event-grid/event-schema-communication-services
https://learn.microsoft.com/en-us/azure/communication-services/concepts/voice-video-calling/call-recording

Kindly let us know if the above helps or you need further assistance on this issue.

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

Hi @Alexander Karaberov

I'm just reaching out to see if your issue has been resolved or if you've had a chance to review my previous comment?

Hi @Golla Venkata Pavani

Thank you for the detailed explanation. It confirms our understanding of the observable behavior, but it does not yet explain the root cause of the approximately 7.5-hour delay. The recording chunks were finalized with endReason = ChunkMaximumTimeExceeded, which we agree is expected for a long recording.

However, at this point, it is still unclear why two specific chunks were delayed by approximately 7 hours while the other chunks from the same recording completed much earlier, especially since you also confirmed that such a multi-hour delay is not documented as expected behavior. Additionally, you mentioned:

this strongly suggests a service‑side delay during recording finalization or export

We would like to receive at least a preliminary conclusion from the backend investigation by the ACS service team. In particular, we would like to understand whether this was a one-off incident caused by sporadic service overload, outage, internal ACS processing backlog, or some form of throttling.

The ACS call recording feature is critical for our customers, and a delay of ~7.5 hours instead of the sub-30-minute latency we usually observe is concerning. We therefore need to understand whether this issue could happen again for long calls under specific conditions, or whether it should be considered highly unlikely to recur.

Best regards,
Alexander

Hi @Alexander Karaberov

Azure Communication Services automatically segments long recordings into multiple chunks, and a chunk ending with endReason = ChunkMaximumTimeExceeded is expected behavior for long‑running calls. Each chunk is processed and finalized independently by the service once its maximum duration is reached.

For BYOS scenarios, metadata and media files are not guaranteed to be exported at the same time. The documentation states that recording metadata and media are only considered ready once ACS completes internal processing and export for that chunk. The Microsoft.Communication.RecordingFileStatusUpdated Event Grid event is published only when the media file for a chunk is fully processed and available, and its timing is directly tied to media availability, not metadata creation.- Metadata files can appear before the media blob.

• RecordingFileStatusUpdated events are emitted only after processing completes.
• Recordings are first stored in temporary ACS storage and then exported to customer storage when processing finishes.

While the documentation notes that events are “typically published a few minutes after processing completes”, this is explicitly not defined as an SLA or guarantee.

As a result, based solely on Microsoft documentation:

• A delay between chunk completion and BYOS export is possible
• Event timing is dependent on backend processing completion
• Multi‑hour delays are not documented as expected behavior, but are also not ruled out by any documented guarantee

Since the delayed chunks were eventually exported successfully and the corresponding events were emitted, the documentation supports the conclusion that the chunks were not lost, and that the delay occurred during internal ACS recording processing prior to export rather than due to customer storage, Event Grid, or configuration issues.

Reference:
https://learn.microsoft.com/en-us/azure/communication-services/concepts/voice-video-calling/call-recording
https://learn.microsoft.com/en-us/azure/communication-services/quickstarts/voice-video-calling/get-started-call-recording?pivots=programming-language-javascript

Kindly let us know if the above helps or you need further assistance on this issue.

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

Hi @Alexander Karaberov

I'm just reaching out to see if your issue has been resolved or if you've had a chance to review my previous comment?