livekit Egres ended with non-complete status: 4

Thanks for reaching out, Hyeonsu. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.

[livekit/webhook] egress_ended: egressId=EG_7u5HmDfkmhy7, status=4

Thanks — I’m responding to your webhook line: "[livekit/webhook] egress_ended: egressId=EG_7u5HmDfkmhy7, status=4". What status=4 means • Status code 4 maps to EGRESS_FAILED — the egress session did not complete successfully. Common causes to check • Upload/storage failures (S3/GCS/Azure permissions, network, or transient errors). • RTMP endpoint rejecting the stream or unreachable RTMP server/invalid stream key. • Internal egress service error during recording/transcoding. • The room ended unexpectedly before egress finished. • Authentication/permission issues for the chosen output destination. Immediate steps to diagnose 1. Retrieve the full

egress_ended

webhook JSON (redact secrets) and look for: ◦

details

or

error

fields in

egressInfo

— they often contain the specific failure message. ◦

backupStorageUsed

— if true, a backup recording was kept for 7 days. 1. Check the corresponding

egress_started

event and correlate timestamps with room lifecycle events (e.g.,

room_finished

) to see if the room ended early. 2. If writing to cloud storage: ◦ Verify bucket name, credentials, IAM/policy permissions, and network access. ◦ Check the storage provider’s logs for rejected uploads. 1. If streaming to RTMP: ◦ Confirm RTMP URL/port is reachable and the stream key is valid. ◦ Check the RTMP target for any rejection or authentication errors. 1. Review your LiveKit server / egress service logs around the egressId timestamp for internal errors or stack traces. What I can do next for you • If you share the

egress_ended

webhook payload (with secrets removed) and any server logs around the egressId EG_7u5HmDfkmhy7, I’ll analyze the `details`/error fields and recommend exact fixes. • If you prefer, tell me the egress type (recording, streaming, track, or segment) and destination (S3/GCS/RTMP/local), and I’ll give targeted troubleshooting steps for that path. You’re on the right track—share the webhook JSON or the two most important items from the checklist above and I’ll help pinpoint the cause and next steps. Sources: Server-side | livekit/livekit_composite | DeepWiki | Backup Egress Recordings

No logs for details/error for the error, can i look up on this somehow?

Thanks — I know it’s frustrating when

egress_ended

shows

status=4

but there are no

details

or

error

fields to explain why. I’ll walk through practical ways to investigate and surface more information so you can find the root cause. Before we dig in: are you running LiveKit self-hosted or using LiveKit Cloud? I’ll tailor the steps based on that; if you’re not sure, tell me how you deployed LiveKit (Docker, k8s, managed service). Steps to investigate when the webhook has no error details 1. Re-check the full webhook payload • Confirm the webhook payload you received has all fields (sometimes middleware or logs truncate fields). If possible, capture the raw webhook HTTP request body and headers. • Look for `egress_started`/`egress_updated` events for the same

egressId

— they can include context or intermediate statuses. 1. Correlate other webhooks and room events • Find

egress_started

,

room_finished

,

participant_left

, or

track_published

events around the same timestamp. These can reveal if the room or egress lifecycle experienced a related event (e.g., room finished unexpectedly). • Compare timestamps to see if a network blip or room event coincides with the egress end. 1. Check backup storage and manifest locations • If backup egress is enabled, check whether

backupStorageUsed

is present (sometimes in separate fields) or look for a

manifestLocation

entry. Backup recordings may be stored even when the main upload failed. • Inspect the backup bucket/manifest for partial files or upload errors. 1. Inspect destination-side logs and permissions • Cloud storage (S3/GCS/Azure): check bucket access logs, object creation/failed upload entries, permission denials, quota/limit errors, and recent credential expirations. • RTMP endpoints: check the RTMP server logs for rejected connections or authentication failures at the egress timestamp. • If the destination uses presigned URLs or temporary credentials, confirm they were valid for the full duration. 1. Review network connectivity and resource constraints • Look for transient network issues between the egress worker and the destination (VPC flow logs, NAT gateway logs, proxy/load balancer errors). • Check CPU/memory and disk on the host running egress — an out-of-memory or disk-full condition can terminate egress without a descriptive error. 1. Enable or increase logging/monitoring • For self-hosted LiveKit: ◦ Increase egress/worker log verbosity (set debug/trace if available) and reproduce. ◦ Collect system logs (syslog, container logs) on the egress worker around the egressId. • For LiveKit Cloud: ◦ Look for any available session or deployment logs in the dashboard that cover the egress timeframe. If you can share timestamps and the egressId, I can point to what to check next. 1. Reproduce with a controlled test • Start a small egress to the same destination with verbose logging and a short duration while monitoring destination logs. If it fails reproducibly, you’ll have tighter correlation for diagnosis. 1. Check for known configuration pitfalls • Ensure output formats, segment durations, and transcode settings are compatible with the destination. • Verify no recent changes to credentials, bucket policies, IAM roles, or retention rules. What I can do for you next • If you can share (redact secrets) any of the following, I’ll inspect them and suggest focused next steps: ◦ The raw

egress_started

and

egress_ended

webhook payloads for

EG_7u5HmDfkmhy7

◦ Timestamps for when the egress started and ended ◦ Destination type (S3/GCS/RTMP/local) and whether backup egress was enabled ◦ Whether LiveKit is self-hosted or cloud-hosted • If you prefer, tell me the top two items you can easily provide (e.g., raw webhook bodies or destination type) and I’ll start there. If you want, I can also give precise commands or log locations for common deployments (Docker, Kubernetes) once you tell me how LiveKit is deployed.

it's LiveKit Cloud

Thanks — since you’re on LiveKit Cloud, that narrows things and I can be specific. I know it’s frustrating to see

egress_ended

with

status=4

while participants remain in the room. Here’s what that status means and practical, LiveKit Cloud–focused steps you can take to find the root cause. What status=4 means • Status code 4 = EGRESS_FAILED. The egress worker failed to complete the recording/streaming job. This is an egress-side failure and can happen even while participants stay connected. What commonly causes EGRESS_FAILED on LiveKit Cloud • Upload/backup destination problems (S3/GCS/Azure) — permissions, expired creds, quotas, or transient provider errors. • RTMP destination issues — unreachable endpoint, invalid stream key, or server rejecting the stream. • Transient network/connectivity issues between LiveKit Cloud egress workers and the destination. • Internal egress processing errors (recording, transcoding, disk space/timeouts on the worker). • Room or resource limits (less likely if participants remain connected, but possible if underlying service hit a limit). What to check in LiveKit Cloud (steps you can do now) 1. Share the raw webhook bodies (egress_started + egress_ended) ◦ Even if `error`/`details` looked empty, please paste the raw JSON (redact any secrets). Sometimes

details

appears in

egressInfo

or other nested fields and can be missed. 1. Provide timestamps for the egress ◦ Give the start and end timestamps for EgressId EG_7u5HmDfkmhy7. With those I can suggest which LiveKit Cloud logs/events to correlate. 1. Tell me the egress destination and config ◦ Destination type: S3, GCS, Azure, RTMP, or LiveKit Cloud storage (backup). ◦ Whether backup egress was enabled (the webhook will set

backupStorageUsed: true

if a backup was used). ◦ If S3/GCS/Azure: whether you used presigned URLs, static access keys, or a role. 1. Check for backup/manifest entries ◦ If backup egress is enabled, the recording may have been saved to a backup bucket for 7 days. Look for a

manifestLocation

in any webhook or dashboard record — that lets you recover the file even when the main upload failed. 1. Look at destination-side logs ◦ For cloud storage: check bucket access logs or audit logs for denied PutObject or authentication failures during the egress timeframe. ◦ For RTMP: check your RTMP server logs for connection attempts, rejects, or auth failures at the same timestamps. 1. Reproduce with verbose monitoring ◦ Run a short test egress to the same destination and monitor destination logs, and capture the raw webhook payloads. If it fails reproducibly, correlation will be straightforward. How I can help next • If you paste (redacted) the raw

egress_started

and

egress_ended

webhook JSON and the start/end timestamps, I’ll: ◦ Inspect for any hidden

details

,

manifestLocation

, or

backupStorageUsed

fields. ◦ Recommend precise checks on the destination (exact permission bits, expected HTTP response codes to look for, or RTMP behaviors). ◦ Suggest a minimal test you can run on LiveKit Cloud to reproduce safely. If you prefer, send just the egressId and timestamps and I’ll tell you the exact log entries and dashboard places to look in LiveKit Cloud next.

track not found

Thanks — "track not found" is a useful clue. I’ll explain what it typically means for LiveKit Cloud egress and give focused next steps to diagnose and fix it. What "track not found" usually means • It usually indicates the egress job asked for a specific track (by track ID or participant/track reference) that wasn't available when the egress ran. • This can happen if the track ID in the egress request was incorrect, the track hadn't been published yet, or the track was unpublished or removed while recording was in progress. Quick checks you can do right now 1. Confirm which egress type you started ◦ Track egress (single track) or track-composite egress? Track-targeted egress requires a valid track identifier. 1. Verify the track IDs and timing ◦ Compare the track ID(s) used in your egress request to the track IDs shown in room events (e.g.,

track_published

) around the egress start time. ◦ Ensure the track was published before the egress started and remained published while egress was running. 1. Share these items (redact secrets) if possible ◦ The raw egress request payload you used to start the job. ◦

egress_started

and

egress_ended

webhook payloads for EG_7u5HmDfkmhy7. ◦ Room event log snippets (timestamps) showing

track_published

/

track_unpublished

for the participant you expected to record. If you don’t have those logs handy, try this targeted test 1. Start a short track egress referencing a currently published track (copy the track ID from a live

track_published

event). 2. Monitor the webhooks in real time and confirm the egress runs without returning "track not found." What I’ll look for if you share data • Mismatch between the track ID in the egress request and the room’s published track IDs. • Timing issues where the egress started before the track existed. • Any evidence the track was unpublished during the egress window. Next best step • If you can paste the egress request payload or the egress_started/egress_ended webhooks (redact credentials), I’ll inspect them and point to the exact field causing "track not found" and the fix (correct track ID, delay egress until publish, or change egress type). If you'd rather, tell me whether you used a track ID, participant/track label, or composite request and I’ll give the exact fields to check. Sources: Backup Egress Recordings | server-sdk-js | livekit/livekit_composite | DeepWiki | Universal Egress | LiveKit | Universal Egress | LiveKit

it's a single track and recording was started correctly but the output file is 4-min long which should've been 20-min long

Thanks — I understand: you started a single-track egress, the participant stayed in the room, but the output file stopped at ~4 minutes instead of the expected ~20 minutes. That short, partial file plus

egress_ended

status=4 means the egress job failed part-way (EGRESS_FAILED). Let’s focus on the most likely causes and the exact information I need to pinpoint the problem. What that 4-minute file implies • The egress worker began recording the track and produced output, but then the egress process terminated with a failure before the full session finished. • Common root causes for a single-track egress stopping early: ◦ The track was unpublished or became unavailable mid-recording (the “track not found” symptom). ◦ An upload/storage error while writing the file to the destination (S3/GCS/Azure) or a failure sending to an RTMP target. ◦ Transient network or connectivity issues between LiveKit Cloud egress workers and the destination. ◦ Internal egress processing error, timeout, or resource constraint on the worker. What I need to investigate this quickly Please share (redact any secrets) or confirm the following: 1) Raw webhook payloads and timestamps • The full

egress_started

and

egress_ended

webhook JSON for EG_7u5HmDfkmhy7. • Exact start and end timestamps for the egress job. 2) Egress request details • The payload you used to start the single-track egress (show which track ID or participant/track reference you passed). 3) Destination and backup settings • Where the egress wrote to: S3, GCS, Azure, RTMP, or LiveKit Cloud backup. • Whether backup egress was enabled (and if so, any

manifestLocation

or

backupStorageUsed

values you saw). 4) Room/track events (if available) • Any

track_published

/

track_unpublished

events for that participant around the egress timeframe. • Whether the track changed (renamed/unpublished) or the participant momentarily lost track publishing. If you can’t share payloads, provide: • Egress start/end timestamps • The track ID you used • Destination type What I’ll do when you share that • Inspect

egress_ended

for any hidden

details

,

manifestLocation

, or

backupStorageUsed

fields. • Correlate timestamps with LiveKit Cloud events to see if the track was unpublished, or if an upload attempt failed. • If it’s a storage/upload issue, point to the exact destination-side log checks (e.g., S3 PutObject denied events) and recommended fixes. • If it’s a track availability/timing issue, recommend how to ensure the track is present before starting egress (or switch to composite/room egress if you need resilience to track changes). Quick triage you can run now • Check whether a backup/manifest exists for that egress — even after failure a backup may allow recovery. • Confirm the track ID used matched a live

track_published

event before the egress started. • Try a short controlled test: start a 30s single-track egress referencing a currently published track and watch webhooks in real time. Send me the egress_started/egress_ended JSON or the three quick facts (timestamps, track ID, destination) and I’ll analyze and give a precise next step.