Skip to main content
Recording failures fall into two buckets: the recording never started, or it started but the output is wrong. Each needs different checks. Transcription is covered at the end.

​
Where recording errors show up

A recording failure can be reported in four places:
  • In the client: the recording-error event fires on the call object with a human-readable errorMsg. Subscribe to it in production apps.
  • On your server: the recording.error webhook fires even when no client is around to hear it. This is the most reliable channel for server-driven recordings.
  • Via the REST API: GET /recordings/:id returns the recording’s status and duration.
  • In the dashboard: the Recordings page lists finished cloud recordings, and the Developers page has an API log of every REST request to your domain with its HTTP status. That log is the fastest way to confirm whether a REST recording-start call reached Daily and what Daily answered.

​
The recording never started

1

Confirm recording is enabled

The room needs enable_recording set, or the participant’s meeting token needs it. If neither has it, startRecording() fires a recording-error with the message startRecording ignored: not enabled, and you won’t get recording-started. See turning on cloud recording.The type you pass to startRecording() also has to be one of the enabled types. enable_recording accepts a comma-separated list, so check the whole list.
2

Check the network at the moment of start

startRecording() is a message sent over the call’s signaling connection. If that connection was interrupted right then, the message never arrived and no error may surface. Listen for network-connection and don’t call startRecording() while signaling is interrupted. If the user’s network was flapping at that moment, this is the most likely cause.
3

Confirm you got recording-started back

recording-started fires for all participants when the recording begins, and for cloud recordings it includes the recordingId. No recording-started and no recording-error within a few seconds means the start request likely never reached Daily.
4

Consider starting from your server

POST /rooms/:name/recordings/start starts a recording without depending on any participant’s network. The HTTP response tells you right away whether it worked. For recordings that must not fail, this is the sturdier pattern, paired with the recording.error webhook for monitoring.

​
The recording is blank or incomplete

The recording pipeline records what it receives. A blank or partial recording almost always means the participants’ media never reached it, not that the recording itself failed.
  • Blank at the start: recording began before anyone had their camera or mic on. In the dashboard’s session event log, compare when participants unmuted with the recording start time.
  • A participant is missing or frozen: check that participant’s dashboard page for the same window. If their uplink had heavy packet loss, the recording got the same broken stream everyone else saw. This is a call quality problem, not a recording problem.
  • The recording cuts off early: check duration and status on GET /recordings/:id, and whether a recording.error webhook fired. Recordings also stop at maxDuration, which defaults to three hours. Compare the duration against the value used at start.
  • Finished but you can’t retrieve it (custom S3 bucket): with your own S3 bucket, upload failures are usually bucket permissions. The recording.error webhook carries the underlying error, for example a failure fetching STS credentials for your role. Re-check the bucket policy and role ARN against the custom S3 guide.

​
Raw-tracks recordings

raw-tracks records each participant’s tracks into your S3 bucket exactly as they arrived, with no compositing step to smooth over problems:
  • Each track’s quality reflects that participant’s own uplink. One person’s packet loss damages only their files.
  • A participant with several network interruptions can produce several track files, one per reconnect.
  • Missing files for one participant usually means their media never flowed during the recording window. Check their dashboard participant page first.

​
Transcription problems

Transcription failures show up in two places:
  • In the client: the transcription-error event.
  • On your server: the transcript.error webhook, whose error field carries the underlying message. As with recordings, custom S3 delivery failures (bucket permissions, role configuration) show up here.
If transcription starts but the transcript is empty or nearly empty, the usual cause is that no usable audio reached the transcriber: mics were muted, or the audio was too quiet or garbled. Check the session in the dashboard to confirm audio was flowing. Finished transcripts and their status are available via GET /transcripts. The transcription guide covers setup.

​
Still stuck?

Collect the recording or transcript ID, the session ID, the room name, and the time window, then follow the pre-support checklist. Also note how you started the recording (startRecording(), the REST API, or a token’s auto-start property), since the answer depends on it.