> ## Documentation Index > Fetch the complete documentation index at: https://docs.daily.co/llms.txt > Use this file to discover all available pages before exploring further. # Debugging recordings and transcription > Diagnose recordings that never started, came out blank or incomplete, and transcription failures. 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`](/reference/daily-js/events/recording-events#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`](/reference/rest-api/webhooks/events/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`](/reference/rest-api/recordings/get-recording) 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 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](/docs/guides/features/recording/index#cloud). 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. `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`](/reference/daily-js/events/network-events#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. [`recording-started`](/reference/daily-js/events/recording-events#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. [`POST /rooms/:name/recordings/start`](/reference/rest-api/rooms/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](/docs/guides/troubleshooting/debugging-call-issues), not a recording problem. * **The recording cuts off early**: check `duration` and `status` on [`GET /recordings/:id`](/reference/rest-api/recordings/get-recording), and whether a `recording.error` webhook fired. Recordings also stop at [`maxDuration`](/reference/daily-js/types/daily-streaming-options), 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](/docs/guides/features/recording/custom-s3-storage), 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`](/docs/guides/features/recording/index#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`](/reference/daily-js/events/transcription-events#transcription-error) event. * **On your server**: the [`transcript.error`](/reference/rest-api/webhooks/events/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`](/reference/rest-api/transcripts/list-transcripts). The [transcription guide](/docs/guides/features/transcription) 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](/docs/guides/troubleshooting/before-contacting-support). Also note how you started the recording (`startRecording()`, the REST API, or a token's auto-start property), since the answer depends on it. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.