Getting marked as ABORTED

Getting Started
1

We are facing an issue with Room Composite Egress where some recordings are getting marked as ABORTED unexpectedly.

2

You didn’t provide any IDs but I took a look at your account and see 3 failed egresses, but they appear to have been started just before the final participant left the room, so the egress never started.

vmaxhealthtech (Info) 3

Screenshot 2026-09-25 161718

4

Thanks for checking this.

We are experiencing this issue intermittently. In some calls, the egress starts successfully, but in a few cases, it appears to be started just before the final participant leaves the room.

Could you please help us understand why this is happening randomly and what would be the recommended approach to prevent it? Should we start the egress immediately after the first participant joins the room instead of triggering it when the call is ending?

Also, is there any way to identify the exact reason why these 3 egresses failed from the LiveKit logs?

5

@vmaxhealthtech @darryncampbell has the cause, so this is about the fix.

Triggering egress near the end of a call is a race by construction. Rooms close once the last participant leaves, so whether your request lands in time isn’t something you control. Hence the intermittency.

Instead of moving the trigger to first join, bind it to the room. Auto egress does that: “When a room is created with CreateRoom, you can set the egress field to have it automatically record the room as a composite.”

  {
    "name": "my-room",
    "egress": {
      "room": {
        "filepath": "bucket-path/{room_name}-{time}",
        "s3": { "bucket": "mybucket", "access_key": "", "secret": "" }
      }
    }
  }

The gotcha: you have to call CreateRoom explicitly. Rooms are “created manually via server API, or automatically, when the first participant joins”, and the auto-created path carries no egress config.

On the status, EGRESS_ABORTED is a separate value from EGRESS_FAILED in the protocol, so it stopped before producing output rather than crashing mid-recording. The per-egress reason needs server-side visibility, so that part is Darryn’s.

6

In addition to Abid’s answer - I also notice you have failing webhooks in your project, i.e. our attempt to call your webhook is failing. This appears to also be the case for rooms with successful Egresses, so is probably unrelated, but it’s worth looking at if your logic to start egress recordings somehow depends on these webhooks.